Если вы выполняете общесистемную установку библиотек D и исходного кода (файлы интерфейса, я полагаю), то наиболее распространенными местами являются /usr/include/<project name> или /usr/local/include/<project name>, если они не конфликтуют с некоторыми существующими C / C ++проект, который хранит заголовочные файлы там.Некоторые программисты D предпочитают также /usr/include/d/ или /usr/local/include/d/ ...
Я для примера использую /usr/di (D import) для этой цели, и у моих библиотечных проектов есть все свои файлы интерфейса.Я объясню, почему мне не нравится иметь там отдельные каталоги проектов.
Независимо от того, какой каталог вы выбираете, вам нужно обновить пути поиска компилятора.
Вот часть моего dmd.conf:
[Environment64]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -I/usr/di -L-L/usr/lib64 -L--export-dynamic -fPIC
, а ldc2.conf выглядит следующим образом:
// default switches appended after all explicit command-line switches
post-switches = [
"-I/usr/include/d/ldc",
"-I/usr/include/d",
"-I/usr/di",
"-L-L/usr/lib64",
];
Если вы предпочитаете иметь отдельный каталог для каждого проекта, вы должны получить -I<path> длякаждый из них.- Мне действительно не нравится такой подход.Тем не менее, он очень популярен среди разработчиков, поэтому вам решать, как организовать файлы D-импорта.Я знаю, насколько разработчикам не нравится подход Java с domain.product.packages, но он прекрасно вписывается в одно место, где находятся все файлы интерфейса D, и, что самое важное, здесь нет столкновений из-за части domain / product ..