Comment éviter de redéfinir VERSION, PACKAGE, etc

Question

Je n'ai pas vu de questions concernant GNU autoconf/automake builds, mais j'espère qu'au moins certains d'entre vous le connaissent déjà. Ici va:

J'ai un projet (je l'appellerai myproject) qui inclut un autre projet (fournisseur). Le projet fournisseur est un projet autonome géré par quelqu'un d'autre. Y compris un projet comme celui-ci est assez straightforward, mais dans ce cas il y a un petit accroc: chaque projet génère son propre fichier config.h, dont chacun définit des macros standard telles que PACKAGE, VERSION, etc. Cela signifie que, lors de la construction, lorsque le vendeur est en cours de construction, je reçois beaucoup d'erreurs comme ceci:

... warning: "VERSION" redefined 
... warning: this is the location of the previous definition 
... warning: "PACKAGE" redefined 
... warning: this is the location of the previous definition 

ce ne sont que des avertissements, pour le moment au moins, mais je voudrais me débarrasser d'eux. La seule information pertinente que j'ai pu trouver avec une recherche Google est this thread sur la liste de diffusion automake, qui n'est pas beaucoup d'aide. Est-ce que quelqu'un d'autre a de meilleures idées?

Answer 1

Quelques notes:

• vous ne l'avez pas dit à quel point config.h a été inclus - avec des guillemets ou crochets. Voir this other question pour plus d'informations sur la différence. En résumé, config.h est généralement inclus avec des guillemets, et non entre crochets, ce qui devrait amener le préprocesseur à préférer le config.h du répertoire du projet (ce qui est généralement ce que vous voulez)
• Vous dites qu'un sous-projet doit inclure le projet englobant config.h Normalement, ce n'est pas du tout ce que vous voulez. Le sous-projet est autonome, et son PACKAGE et VERSION devrait être celui de ce sous-projet, pas le vôtre. Si vous incluez libxml dans votre projet xmlreader par exemple, vous voudrez toujours que le code libxml soit compilé avec PACKAGE libxml et VERSION (quelle que soit la version de libxml).
• Il est généralement une grande erreur d'avoir config.h être inclus dans les en-têtes publics. config.h est toujours privé pour votre projet ou le sous-projet et ne doit être inclus qu'à partir des fichiers .c. Donc, si la documentation de votre fournisseur dit d'inclure leur "vendeur.h" et que l'en-tête public inclut config.h d'une manière ou d'une autre, alors c'est un non-non. De même, si votre projet est une bibliothèque, n'incluez pas config.h à partir de vos en-têtes installés publiquement.

Answer 2

Il est certainement un hack, mais je post-traiter le fichier autogen'd config.h:

sed -e 's/.*PACKAGE_.*//' <config.h> config.h.sed && mv config.h.sed config.h 

Ceci est tolérable dans notre environnement de construction, mais je serais intéressé d'une manière plus propre.

Answer 3

Il s'est avéré qu'il y avait une solution très simple dans mon cas. Le projet fournisseur rassemble plusieurs fichiers d'en-tête dans un fichier d'en-tête monolithique, qui est ensuite #include d par les sources du fournisseur. Mais la règle make qui construit l'en-tête monolithique incluait accidentellement le config.h généré. La présence des variables de configuration PACKAGE, VERSION, etc. dans l'en-tête monolithique est à l'origine des avertissements de redéfinition. Il s'avère que config.h du fournisseur était hors de propos, car "config.h" toujours résolu à $(top_builddir)/config.h. Je crois que c'est la façon dont il est censé fonctionner. Par défaut, un sous-projet doit inclure le config.h du projet englobant au lieu du sien, sauf si le sous-projet inclut explicitement le sien, ou manipule le chemin INCLUDE de sorte que son propre répertoire précède $(top_builddir), ou manipule autrement les fichiers d'en-tête comme dans mon cas.