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

Question

Je n'ai vu aucune question relative aux versions GNU autoconf/automake, mais j'espère qu'au moins certains d'entre vous le connaissent.Voici:

J'ai un projet (je l'appellerai mon projet) qui inclut un autre projet (fournisseur).Le projet du fournisseur est un projet autonome géré par quelqu'un d'autre.Inclure un projet comme celui-ci est assez direct, mais dans ce cas il y a un petit problème :chaque projet génère le sien config.h fichier, dont chacun définit des macros standards telles que PACKAGE, VERSION, etc.Cela signifie que, pendant la construction, lorsque le fournisseur est construit, j'obtiens de nombreuses erreurs comme celle-ci :

... 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, du moins pour le moment, mais j'aimerais m'en débarrasser.La seule information pertinente que j'ai pu trouver avec une recherche Google est ce fil de discussion sur la liste de diffusion automake, ce qui n'est pas d'une grande aide.Quelqu'un d'autre a-t-il de meilleures idées ?

Answer 1

Quelques notes:

• tu n'as pas mentionné comment config.h a été inclus - avec des guillemets ou des crochets angulaires.Voir cette autre question pour plus d’informations sur la différence.En bref, config.h est généralement inclus avec des guillemets, et non avec des crochets angulaires, ce qui devrait inciter le préprocesseur à préférer le config.h à partir du propre répertoire du projet (ce qui est généralement ce que vous voulez)
• Vous dites qu'un sous-projet devrait inclure le projet englobant config.h Normalement, ce n'est pas du tout ce que vous souhaitez.Le sous-projet est autonome, et son PACKAGE et sa VERSION doivent être ceux de ce sous-projet, pas le vôtre.Si vous incluez libxml dans votre projet xmlreader par exemple, vous souhaiterez toujours que le code libxml soit compilé avec PACKAGE libxml et VERSION (quelle que soit la version de libxml).
• C'est généralement une grave erreur d'avoir config.h être inclus à partir des en-têtes publics. config.h est toujours privé de votre projet ou du sous-projet et ne doit être inclus qu'à partir de fichiers .c.Ainsi, si la documentation de votre fournisseur indique d'inclure son "vendor.h" et que cet 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 n'importe où à partir de vos en-têtes installés publiquement.

Answer 2

C'est définitivement un hack, mais je post-traite l'autogénération config.h déposer:

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

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

Answer 3

Il s'avère qu'il existait une solution très simple dans mon cas.Le projet du fournisseur rassemble plusieurs fichiers d'en-tête en un seul fichier d'en-tête monolithique, qui est ensuite #included par les sources du fournisseur.Mais la règle de création qui construit l'en-tête monolithique incluait accidentellement le fichier généré. config.h.La présence du PACKAGE, de la VERSION, etc.Les variables de configuration dans l'en-tête monolithique sont à l'origine des avertissements de redéfinition.Il s'avère que le vendeur config.h n'était pas pertinent, car "config.h" était toujours résolu en $(top_builddir)/config.h.

Je crois que c'est ainsi que cela est censé fonctionner.Par défaut, un sous-projet doit inclure le projet englobant config.h au lieu du sien, à moins que le sous-projet n'inclue explicitement le sien ou ne manipule le chemin INCLUDE pour que son propre répertoire vienne avant $(top_builddir), ou manipule autrement les fichiers d'en-tête comme dans mon cas.