В настоящее время я использую систему сборки на основе SCons, за которую я не отвечаю, но могу предоставить информацию для сопровождающего.
Одна из проблем, с которой он сталкивается, связана с зависимостями между исходными пакетами C ++. В системе каждый исходный пакет создается в виде библиотеки DLL в Windows или общей библиотеки в Linux.
Предположим, что пакет A включает зависимости от пакетов B и C. B и C указаны в пакете SConscript пакета A. Это отлично. DLL для пакета A также будет связана с DLL для B и C. Это также хорошо, так как любые зависимости ссылок, которые есть у B и C, уже будут разрешены при создании этих DLL.
Сложность связана с пакетами, с которыми связаны юнит-тесты. Здесь нам нужно знать полный, рекурсивно расширенный список библиотечных зависимостей по двум основным причинам:
- Создание модульного теста включает в себя создание сценария, который устанавливает PATH и вызывает исполняемый файл. Запись должна быть добавлена в PATH для каждой зависимости времени выполнения.
- Для связывания исполняемого файла модульного теста в Linux необходим полный расширенный список библиотечных зависимостей. Это отличается от Windows, где модель связывания DLL означает, что косвенные зависимости уже учтены.
Мы не хотим явно указывать полностью расширенный список зависимостей, потому что это слишком многословно и проблема обслуживания.
Текущая система, которая все еще глючит, требует от нас только указать прямые зависимости в пакете SConscripts, но разрешает косвенные зависимости через код Python в SConstruct. Этот код открывает и анализирует файлы SConscript и создает карту зависимостей из извлеченной информации. Такой подход кажется неправильным. Интуитивно я чувствую, что должен быть способ сделать это более естественным путем, используя нативные возможности SCons, но я недостаточно знаком с SCons, чтобы предложить лучший способ. Есть ли лучший способ и что это?