Имитация (но не дублирование) имена каталогов

Обычно мы не кодируем в вакууме и что мы пишем, основано на том, что другие записали перед нами. При принятии программ C и связанного заголовка (.h) файлы создаются на другой программной системе затем, необходимо смоделировать структуру каталогов после их.

, Так как я понятия не имею о Вашей среде, позволяет, берут общую программу и видят, какую структуру каталогов они использовали для их заголовочных файлов:

$ `gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include
End of search list.

у меня нет специального C или библиотек заголовка, установленных в моей системе, таким образом, все должны смочь копировать этот поиск "из поля".

, Когда Вы выполняете развертку в: /usr/include/x86_64-linux-gnu/c++/5 Вы замечаете, что заголовочные файлы включены с программами C. Таким образом, нет жесткого правила, что заголовки должны быть в их собственном каталоге.

Когда дело доходит до программирования можно поместить файлы где угодно, Вы хотите и называете их чем-либо, что Вы хотите. Конечно независимо от того, что Вы решаете, это должно иметь смысл Вам и Вашим коллегам.

, Где заголовочные файлы хранятся теперь

Проверка, где заголовочные файлы хранятся теперь:

$ locate *version.h*
/lib/firmware/carl9170fw/include/shared/version.h
/usr/include/linux/version.h
/usr/include/linux/dvb/version.h
/usr/include/x86_64-linux-gnu/gnu/libc-version.h
/usr/lib/python3/dist-packages/lxml/includes/lxml-version.h
/usr/lib/x86_64-linux-gnu/perl/5.22.1/CORE/git_version.h
/usr/src/linux-headers-3.16.53-031653/include/uapi/linux/dvb/version.h
/usr/src/linux-headers-3.16.53-031653/include/xen/interface/version.h
/usr/src/linux-headers-3.16.53-031653-generic/include/config/localversion.h
/usr/src/linux-headers-3.16.53-031653-generic/include/config/arch/want/compat/ipc/parse/version.h
/usr/src/linux-headers-3.16.53-031653-generic/include/config/isdn/diversion.h
/usr/src/linux-headers-3.16.53-031653-generic/include/generated/uapi/linux/version.h
/usr/src/linux-headers-4.10.0-28/include/uapi/linux/dvb/version.h
/usr/src/linux-headers-4.10.0-28/include/xen/interface/version.h
/usr/src/linux-headers-4.10.0-28-generic/include/config/localversion.h
/usr/src/linux-headers-4.10.0-28-generic/include/config/arch/want/compat/ipc/parse/version.h
/usr/src/linux-headers-4.10.0-28-generic/include/config/isdn/diversion.h
/usr/src/linux-headers-4.10.0-28-generic/include/generated/uapi/linux/version.h

Это - просто верхняя часть моего списка. Это продолжается экстенсивно.

На основе существующих местоположений заголовочного файла, я был бы склонен создать каталог:

/usr/include/ourcompany/

для хранения всего заголовка (.h) файлы.

Рассматривают путь поиска по умолчанию

Однако, поскольку другие указали, что популярное местоположение:

/usr/local/include/

В эта статья , записанная Richard Stallman и другими, они пишут:

По умолчанию, gcc ищет следующие каталоги заголовочные файлы:

/usr/local/include/
/usr/include/

и следующие каталоги для библиотек:

/usr/local/lib/
/usr/lib/

В МОЕЙ системе, /usr/local/include/ каталог существует и пуст. В Стандарте Иерархии Filsystem говорится, что (FHS 3.0) каталог для использования /usr/local/include. Файлы должны быть читаемыми миром (0444) и каталоги должны быть доступными для поиска (0555).

Вопрос, чего Вы хотите достигнуть?

Обычно у Вас есть три сценария:

• разработка
• локальная установка (в Вашем $HOME)
• глобальная установка

Для первых 2 необходимо, вероятно, использовать -I переключатель для предоставления пути к заголовкам. Первое, вероятно, было бы -I../mylib/include, второе может быть -I/home/user/local_libs/somelib/include.

Третий является глобальной установкой, которая должна разместить их в /usr/local/include, но управляемый инструментом любят, автоделают или cmake. При упаковке специалист по обслуживанию должен адаптировать installpath и/или включать путь для установки заголовков на /usr/include.

Когда использование автоделает, у Вас могут быть уведомления, чем --prefix значения по умолчанию параметра к /usr/local для безопасной установки, которая не вмешивается в системные пакеты, в то время как т.е. debian выполненные специалисты по обслуживанию ./configure --prefix=/usr в их сценариях пакета. Включать путь создается из этого префикса, таким образом, он следует за установкой пакета.