Есть ли способ предотвратить рекурсивное сканирование Boost.Build заголовочных файлов для директив #include? - PullRequest
5 голосов
/ 16 апреля 2009

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

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

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

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

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

Ответы [ 2 ]

3 голосов
/ 28 апреля 2009

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

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

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

1 голос
/ 22 апреля 2009

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

Вот выдержка из справочной страницы .

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

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

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

...