comment définir les chemins d'inclusion avec les autotools

Je suis en train de travailler sur un projet C++ qui utilise autoconf & automake, et j'ai du mal à configurer correctement les chemins à inclure dans *CPPFLAGS. J'ai lu environ 3 heures de documents, et je ne peux pas le comprendre encore. Je ne suis pas à la recherche d'un hack, mais pour la manière correcte de le faire. Voici mon énigme.

Comme je le vois, il y a 3 complètement différentes sources pour les chemins d'inclusion:

  1. Bibliothèques externes qui doivent être installés le long de mon colis, qui sont configurés par configure --with-XXX=<PATH>.
  2. À l'intérieur de mon colis, certains fichiers source utiliser #include <file.h> même lorsque file.h fait partie de l'emballage, de sorte à les compiler, je dois définir le chemin de l'correctement. (Remarque, ce n'est pas une option permettant de modifier l'ensemble de ces fichiers).
  3. Lunatique (ou pas) des normes de spécifier l'utilisateur doit être autorisé à spécifier leurs propres (en supplément) comprennent des chemins. C'est, je ne dois pas être la mise en CPPFLAGS à tous.

Dans ma configuration actuelle:

  • De Type 1, les chemins d'accès sont définies à l'intérieur de configure.ac par AC_SUBST(CPPFLAGS, "$CPPFLAGS -I<path>").
  • De Type 2 chemins d'accès sont définis à l'intérieur Makefile.am par test_CPPFLAGS = -I<path>.
  • De Type 3 ne peut pas être définie. Plus exactement, si l'utilisateur définit CPPFLAGS avant d'exécuter make, il remplace de Type 1 paramètres, provoquant la compilation échoue. Bien sûr, l'utilisateur pourrait essayer d'utiliser CXXFLAGS à la place, mais que l'on a une utilisation différente (rappelez-vous, je vous demande la bonne façon de le faire, pas un hack).

J'ai essayé de résoudre ce par Type de paramètre 1 chemins à l'aide de AM_CPPFLAGS à l'intérieur de configure.ac. (Pour référence: si vous définissez AM_CPPFLAGS au lieu de CPPFLAGS, mais vous avez encore besoin d'un tel contrôle AC_CHECK_HEADERS, vous avez besoin de mettre temporairement de CPPFLAGS et revenir ensuite pour les vérifications de travail, ce qui est expliqué ici.) Cela libère de la CPPFLAGS de Type 3 chemins, mais malheureusement, la compilation échoue parce que le Makefile-s qui est produite par configure utilisera uniquement AM_CPPFLAGS si non spécialisés <target>_CPPFLAGS existe. Donc, si test_CPPFLAGS existe avec un Type 2 chemin de la compilation test échoue, car il n'a pas obtenir le Type 1 chemin.

Un correctif serait de spécifier à l'intérieur de Makefile.am de toujours utiliser AM_CPPFLAGS. Mais est-ce "par le livre"? Puis-je faire cela de manière globale, ou dois-je modifier chaque target_CPPFLAGS? Est-il une autre solution "correcte"?

Par "lunatique", incluez-vous les officiel autoconf documentation qui indique clairement que CPPFLAGS est une variable utilisateur ne doit pas être modifié par le responsable? (Voir la section 4.8.1 gnu.org/software/autoconf/manual/autoconf.html)
Bien que moins ambigu exemple de l'officiel automake de la documentation ne peut être plus clair, qui stipule que "Vous ne devriez jamais redéfinir une variable utilisateur comme CPPFLAGS dans le Makefile.suis.", à l'article 27.6 gnu.org/software/automake/manual/html_node/...

OriginalL'auteur Matei David | 2013-11-27

  1. 20

    Je sais que c'est difficile d'obtenir une réponse directe à partir de la autotools manuels. Il ya un couple de bonne start-to-finish tutoriels ici et ici.

    Il n'y a pas une variable standard pour le package spécifique *CPPFLAGS dans autoconf. configure peut être invoqué avec CPPFLAGS=..., et automake va ajouter ce CPPFLAGS à la makefile règles de recherche pour CPPFLAGS dans un Makefile.in fichier pour des exemples. Pour cette raison, je vous suggère de pas utiliser cette variable pour autre chose.

    Ajouter des drapeaux dans les Makefile.am à la AM_CPPFLAGS variable (la valeur par défaut pour tous les préprocesseur appels) ou de remplacer individu préprocesseur drapeaux avec target_CPPFLAGS. Dans l'exemple de la 3e partie de la bibliothèque, il est préférable d'utiliser un nom comme: FOO_CPPFLAGS de tenir des options de préprocesseur, par exemple,

    FOO_CPPFLAGS="-I${FOO_DIR}/include -DFOO_BAR=1"
...
AC_SUBST(FOO_CPPFLAGS)

    et dans le Makefile.am :

    AM_CPPFLAGS = -I$(top_srcdir) $(FOO_CPPFLAGS)
# or:
target_CPPFLAGS = -I$(top_srcdir) $(FOO_CPPFLAGS)

    La top_srcdir variable est définie par configure - je l'utiliser pour illustrer le 2ème cas. Disons que vous avez file.h dans un autre répertoire other, sous le répertoire de niveau supérieur. -I$(top_srcdir) vous permet de l'inclure comme <other/file.h>. Sinon, -I$(top_srcdir)/other vous permettrait de l'inclure comme <file.h>.

    Un autre utile préréglage variable est srcdir - le répertoire courant. -I$(srcdir) est ajouté à AM_CPPFLAGS par défaut. Donc, si file.h est dans le répertoire courant, vous pouvez l'inclure avec <file.h> ou même "file.h". Si other était un 'frère' répertoire, -I$(srcdir)/.. vous permettra d'inclure <other/file.h>, et -I$(srcdir)/../other permettrait <file.h>.

    Je voudrais aussi ajouter que certains paquets installer un pkg-config .pc fichier. Pourvu que l'installation de pkg-config est mis en place pour rechercher les bons répertoires, vous pouvez trouver le PKG_CHECK_MODULES macro très utile.

    Un autre est $(builddir) ou $(top_builddir) qui, apparemment, est destiné à être utilisé pour tous les fichiers que est généré lors d'une compilation.

    OriginalL'auteur Brett Hale