Есть ли способ предотвратить Boost.Build из рекурсивного сканирования файлов заголовков для директив #include?

Question

Есть ли способ ограничить файлы заголовков, которые Boost.Build рекурсивно сканирует для директив #include в определенном каталоге или наборе каталогов? То есть Я бы хотел, чтобы он рекурсивно просматривал файлы заголовков только в моем проекте. Я знаю, что внешние зависимости не изменятся (и, будучи Boost и Qt, они довольно большие). В итоге я получаю около 50 000 целей в дереве зависимостей, которые требуют времени для обработки (в результате получается 1-2-минутное время сборки, даже если файлы фактически не изменились).

Единственное решение, которое я нашел до сих пор, заключается в том, чтобы использовать переменную среды INCLUDE (я использую MSVC) - это значит, что Boost.Build не нужно информировать о путях include (я использую эту функцию) и, следовательно, не будет сканировать их. Это кажется немного взломанным.

Я чувствую, что мне, должно быть, недостает чего-то очевидного, потому что я не мог найти других людей, испытывающих подобные проблемы, хотя я столкнулся с этим почти сразу. Ближайший я пришел here.

Судя по выходному отладку (bjam -d 3), он также просматривает большинство файлов заголовков более одного раза ... Я не знаю, означает ли это, что они добавляются как зависимости более одного раза, но, безусловно, стоимость загрузки файла и сканирование всего содержимого должны складываться?

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

Answer 1

Этот вопрос был также размещен в списке рассылки Boost, и мы получили ответ на него здесь: http://lists.boost.org/boost-build/2009/04/21734.php.

Итак, кажется, что ответ на этот вопрос, по крайней мере, из коробки, Boost.Build не имеет этой функции, и решение заключается в настройке Boost.Постройте свои потребности, что делает определенный смысл.

Тем не менее, мне все еще интересно, почему это не более распространенная проблема для людей. Я вижу, что кэширование зависимостей сократило бы время, но, конечно, если мы сканируем все внешних библиотек, мы получим огромное дерево зависимостей, большая часть которого будет избыточной? Когда я работаю над проектом, я не собираюсь часто менять сторонние библиотеки вообще, кажется, стыдно платить за проверку зависимостей на них.

Answer 2

Возможно, вы захотите проверить альтернативные инструменты сборки, такие как SCons. У SCons есть режим --imclicit-cache, где он кэширует неявные зависимости. Это должно помочь в описанном вами сценарии.

Вот выдержка из man page.

--imclicit-cache
Неявные зависимости кэша. Это заставляет scons использовать неявные (отсканированные) зависимости от последнего запуска, вместо того, чтобы сканировать файлы для неявных зависимостей. Это может значительно ускорить работу SCons, но со следующими ограничениями: scons не обнаружит изменений в пути поиска неявных зависимостей (например, CPPPATH, LIBPATH), которые обычно приводят к использованию разных версий файлов с одинаковыми именами. scons пропустит изменения в неявных зависимостях в случаях, когда новая неявная зависимость добавляется ранее в пути поиска неявной зависимости (например, CPPPATH, LIBPATH), чем текущая неявная зависимость с тем же именем.

--implicit-deps-changed
Заставляет SCons игнорировать кэшированные неявные зависимости. Это приводит к тому, что неявные зависимости подлежат повторному сканированию и повторному копированию. Это подразумевает --imble-cache.

--implicit-deps-unchanged
Force SCons игнорировать изменения в неявных зависимостях. Это приводит к постоянному использованию кэшированных неявных зависимостей. Это подразумевает --imble-cache.