Зависимости от заголовочных файлов между модулями C++

Разве не было бы более интуитивно понятным поместить заголовки интерфейса в корень проекта и создать подпапку (назовите ее «внутренняя» или «вспомогательная» или что-то в этом роде) для заголовков, не относящихся к API?

Я видел проблемы, подобные этой, которые решались с помощью набора заголовков в модуле B, которые копируются в каталог выпуска вместе с библиотекой как часть процесса сборки. Модуль A тогда видит только эти заголовки и никогда не имеет доступа к внутренним компонентам B. Обычно я видел это только в большом проекте, который был выпущен публично.

Для внутренних проектов этого просто не бывает. Обычно случается, что когда они маленькие, это не имеет значения. И когда они вырастают, их так беспорядочно отделять, что никто не хочет этого делать.

Где я работаю, у нас есть структура папки доставки, созданная во время сборки. Заголовочные файлы, определяющие библиотеки, копируются во включаемую папку. Мы используем специальные сценарии сборки, которые позволяют разработчику определять, какие файлы заголовков следует экспортировать.

Наша сборка затем внедряется на диск subst ed, что позволяет нам использовать абсолютные пути для подключаемых каталогов.

У нас также есть эталонная сетевая сборка, которая позволяет нам использовать подключенный диск для ссылок на include и lib.

ОБНОВЛЕНИЕ: Наша эталонная сборка - это сетевой ресурс на нашем сервере сборки. Мы используем эталонный сценарий сборки, который настраивает среду сборки и отображает (используя net use ) именованный общий ресурс на сервере сборки (то есть \ BLD_SRV \ REFERENCE_BUILD_SHARE).

Обычно я просто вижу каталог include, в который складываются все заголовки интерфейса. Это, безусловно, упрощает включение заголовков. Людям все еще приходится думать о том, от каких модулей они зависят, когда они определяют модули для компоновщика.

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

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

Однако, если ваши проекты имеют плоскую иерархию, это сработает.

Похоже, вы на правильном пути. Многие сторонние библиотеки делают то же самое. Например:

3rdParty / myLib / src / -содержит заголовки и исходные файлы, необходимые для компиляции библиотеки
3rdParty / myLib / include / myLib / - содержит заголовки, необходимые для включения внешних приложений

Некоторые люди / проекты просто помещают заголовки для включения внешними приложениями в / 3rdParty / myLib / include, но добавление дополнительного каталога myLib может помогают избежать коллизии имен.

Предполагая, что вы используете структуру: 3rdParty / myLib / include / myLib /

In Makefile of external app:
---------------
INCLUDE =-I$(3RD_PARTY_PATH)/myLib/include
INCLUDE+=-I$(3RD_PARTY_PATH)/myLib2/include
...
...

In Source/Headers of the external app
#include "myLib/base.h"
#include "myLib/object.h"

#include "myLib2/base.h"

В группе, с которой я работал, все общедоступное хранилось в папке для конкретного модуля, а личные данные (частный заголовок, файл cpp и т. Д.) Хранились в _imp внутри этой папки:

base\foo\foo.h
base\foo\_imp\foo_private.h
base\foo\_imp\foo.cpp

Таким образом, вы можете просто взять внутри структуры папок вашего проекта и получить нужный заголовок. Вы можете найти директивы #include, содержащие _imp , с помощью grep и внимательно их изучить. Вы также можете взять всю папку, скопировать ее куда-нибудь и удалить все подпапки _imp , зная, что у вас будет все готово для выпуска API. В заголовках проектов, которые обычно включаются как

#include "foo/foo.h"

Однако, если проект должен использовать какой-либо API, тогда заголовки API будут скопированы / установлены сборкой API, где бы они ни были на этой платформе системой сборки, а затем установлены. как системные заголовки:

#include <foo/foo.h>