Évitez d'ajouter « chemins » pour inclure les en-têtes qui ne sont pas directement #include

Question

Supposons que j'ai deux vC++ projet, proj_a et proj_b

proj_a contient un fichier d'en-tête a.h

proj_b a dépendance à l'égard proj_a. Il contient le fichier b.h qui #include <a.h>. J'ajoute le répertoire de a.h dans les "répertoires include supplémentaires" dans ses paramètres de projet pour le construire.

Maintenant, disons, j'ai 100 autres projets, dont les fichiers #include <b.h>. Le seul ajout du répertoire b.h dans la colonne "additional" ne fonctionne pas. Je dois aussi inclure le chemin de a.h .. Comment éviter cela?

Simplement dit, comment maintenir le nombre de chemins d'inclusion pour tout projet vC++ égal au nombre de dépendances directes?

Je n'ai pas la possibilité de définir vC++ paramètres d'environnement pour inclure globalement le chemin de ah puisque tout le monde dans mon équipe devra importer mes paramètres et les choses vont tourner messier ..

Je ne pas avoir assez d'idée, mais y a-t-il un moyen d'y parvenir grâce à des en-têtes précompilés? Je pense qu'ils sont spécifiques à un projet et ne devraient pas être partagés entre plusieurs projets?

Answer 1

Les dépendances sont transitives. Autrement dit, puisque b.h comprend a.h, tout ce qui comprend b.h devra être en mesure de trouver a.h. La seule chose que vous pouvez faire à ce sujet est de supprimer la dépendance de b.h sur a.h, peut-être en utilisant une déclaration avant pour les types dans a.h au lieu de s'appuyer sur la définition complète des types du fichier d'en-tête.

Si ce n'est pas une option, au moins vous pouvez alléger le problème des chemins d'inclusion qui sont dupliqués à travers les projets en utilisant Visual C++'s "property sheet" feature. Ceux-ci vous permettent de définir des paramètres de construction partagés dans un seul fichier qui peut être hérité par un nombre arbitraire de projets. Cela permettra également de résoudre le problème de partage de ces paramètres avec vos collaborateurs.

Answer 2

Merci pour la réponse Nick. J'aurais pu utiliser le chemin relatif à a.h à l'intérieur de b.h et enregistrer les répertoires supplémentaires-include dans proj_b et le reste des 100 projets.

En fait, dans mon cas, il y a plusieurs variantes de proj_a: 'proj_a1, proj_a2, etc. ayant chacune un a.h. Les 100 autres projets décident de la saveur à inclure en disposant d'un répertoire supplémentaire-include approprié dans leurs paramètres. C'était un problème, chaque fois que nous avons besoin de mettre à jour les saveurs de proj_a, tous les répertoires include devront être changés.

J'ai rencontré ce problème en supprimant tous les répertoires d'inclusion et en définissant à la place PROJ_A1, PROJ_A2, etc. dans le reste des projets. b.h ne fait plus #include a.h, il inclut un fichier d'en-tête a_redirector.h à la place (avec un chemin relatif). A l'intérieur a_redirector.h, nous avons tous #ifdef PROJ_A1, #ifdef PROJ_A2, etc qui regarde le fichier a.h particulier (chemins relatifs ici aussi) en fonction de ce qui a été défini.

Maintenant, chaque fois que nous avons besoin de mettre à jour proj_a flavors, j'ai seulement besoin de modifier a_redirector.h seulement pour pointer tout nouveau a.h ayant ainsi un seul point de contrôle par rapport à l'architecture précédente.