Est-il possible d'empêcher Boost.Build d'analyser de manière récursive les fichiers d'en-tête pour les directives #include?

Question

Existe-t-il un moyen de limiter les fichiers d'en-tête que Boost.Build analyse de façon récursive pour les directives #include à un répertoire particulier ou un ensemble de répertoires? C'est à dire. Je voudrais qu'il scanne récursivement les fichiers d'en-tête dans mon projet seulement. Je sais que les dépendances externes ne vont pas changer (et étant Boost et Qt ils sont assez gros). Je me retrouve avec environ 50 000 cibles dans l'arbre des dépendances, ce qui prend du temps à traiter (ce qui donne un temps de construction de 1 à 2 minutes même si aucun fichier n'a réellement changé). La seule solution que j'ai trouvée jusqu'ici est de tirer parti de la variable d'environnement INCLUDE (j'utilise MSVC) - cela signifie que Boost.Build n'a pas besoin d'être informé des chemins d'inclusion (j'utilise la fonctionnalité) et ne les analysera donc pas. Cela semble un peu un hack. Je sens que je dois manquer quelque chose d'évident parce que je n'ai pas été capable de trouver d'autres personnes rencontrant des problèmes similaires, même si j'ai rencontré cela presque immédiatement. Le plus proche, je suis venu est here. A en juger par la sortie de débogage (bjam -d 3), il scanne aussi la plupart des fichiers d'en-tête plus d'une fois ... Je ne sais pas si cela signifie qu'ils sont ajoutés en tant que dépendances plus d'une fois, mais certainement le coût de chargement d'un fichier et l'analyse de l'ensemble du contenu doit s'additionner? Si je pouvais lui dire de ne pas déranger la numérisation d'un répertoire particulier ou d'un ensemble de répertoires dans lesquels je peux garantir que les fichiers d'en-tête ne vont pas changer, ce serait parfait.

Answer 1

Cette question a été aussi postée sur la liste de diffusion Boost et nous avons obtenu une réponse ici: http://lists.boost.org/boost-build/2009/04/21734.php.

Donc, il semble si loin que la réponse est que Boost.Build n'a pas cette fonctionnalité, et la solution est de personnaliser Boost.Construire à vos besoins, ce qui a un certain sens.

Cependant, je suis toujours curieux de savoir pourquoi ce n'est pas un problème plus commun pour les gens. Je vois que la mise en cache des dépendances réduirait le temps, mais sûrement si nous analysons toutes les bibliothèques externes nous nous retrouvons avec un énorme arbre de dépendance, en grande partie redondant? Quand je travaille sur un projet, je ne vais pas changer du tout les bibliothèques tierces très souvent, il semble dommage de payer pour la vérification des dépendances.

Answer 2

Vous voudrez peut-être consulter d'autres outils de construction comme SCons. SCons a un mode --implicit-cache où il met en cache les dépendances implicites. Cela devrait aider dans le scénario que vous avez décrit. Voici un extrait du man page.

--implicit-cache
dépendances implicites de cache. Cela provoque scons à utiliser les dépendances implicites (analysées) de la dernière fois qu'il a été exécuté au lieu d'analyser les fichiers pour les dépendances implicites. Cela peut considérablement accélérer SCons, mais avec les limitations suivantes: scons ne détectera pas les modifications apportées aux chemins de recherche de dépendances implicites (par exemple CPPPATH, LIBPATH) qui entraîneraient normalement l'utilisation de différentes versions de fichiers du même nom. des changements dans les dépendances implicites dans les cas où une nouvelle dépendance implicite est ajoutée plus tôt dans le chemin de recherche de dépendance implicite (par exemple CPPPATH, LIBPATH) qu'une dépendance implicite actuelle avec le même nom.

--implicit-deps-changed
Force les entités SCons à ignorer les dépendances implicites mises en cache. Cela provoque les dépendances implicites à rescanned et à recacheter. Cela implique --implicit-cache.

--implicit-deps-inchangé
Force SCons à ignorer les modifications dans les dépendances implicites. Cela provoque toujours les dépendances implicites mises en cache à toujours être utilisées. Cela implique --implicit-cache.