Automake AM_LDADD solution de contournement

Question

Je souhaite définir le même attribut LDADD (bibliothèque de tests unitaires) sur un grand nombre de cibles (fichiers unitaires de test C++). Je pense d'abord que peut-être automake a la variable AM_LDADD pour ajouter cette bibliothèque à toutes les cibles dans le fichier mais ce n'est pas le cas. Dans une liste de courrier, j'ai trouvé une brève discussion demandant de l'ajouter: http://gnu-automake.7480.n7.nabble.com/AM-LIBS-AM-LDADD-td3698.html

Ma question est, comment gérez-vous cela? est-il possible d'éviter d'ajouter manuellement l'attribut LDADD à chaque cible?

mon Makefile.am regarde Jusqu'à présent, comme:

test1_SOURCES = ... 
test1_LDADD = -llibrary 
    ... 
    ... 
test20_SOURCES = ... 
test20_LDADD = -llibrary 

Answer 1

L'équivalent d'une variable AM_LDADD est tout simplement LDADD. par exemple,

LDADD = -llibrary 

test1_SOURCES = ... 
... 
test20_SOURCES = ... 

Si vous avez besoin de passer outre LDADD pour un programme particulier: prog, puis prog_LDADD aura toujours la priorité.

Je suppose toujours que, puisqu'il n'y avait pas de variable d'environnement standard LDADD passé à configure - comme vous pouvez le voir avec configure --help - il n'y a aucune raison pour un AM_LDADD. Ce genre de logique, comme le script configure, et toutes les options, par exemple, --with-foo=<path> devraient (idéalement) travailler sur les dépendances de la bibliothèque.

D'autre part, en passant par CFLAGSconfigure pourrait encore avoir besoin d'un AM_CFLAGS qui combine CFLAGS et avec d'autres drapeaux du compilateur déterminés par le script de configuration; ou même un override foo_CFLAGS. Depuis configure doit être informé de votre personnalisation CFLAGS.

---

De plus, je ne sais pas si les programmes test<n> ne prennent qu'un seul fichier source C++, mais le cas échéant, vous pouvez simplifier le Makefile.am avec:

LDADD = -llibrary 

check_PROGRAMS = test1 test2 ... test20 
AM_DEFAULT_SOURCE_EXT = .cC# or .cpp 

comme décrit here.

---

En ce qui concerne votre commentaire, votre peut utiliser un convenience library à cette fin - ce qui est particulièrement utile pour le code commun utilisé par les programmes de test:

noinst_LIBRARIES = libfoo.a # or noinst_LTLIBRARIES = libfoo.la 
libfoo_a_SOURCES = MyClass.hh MyClass.cc # or libfoo_la_SOURCES 

LDADD = ./libfoo.a -llibrary # or libfoo.la if using libtool. 

... etc ... 

Answer 2

C'est une mauvaise idée de modifier LDADD dans votre Makefile.am, même si cela semble pratique. Cela rendra votre système de construction très fragile.

En particulier, si l'utilisateur tente de passer outre LDADD de la ligne de commande make, votre définition de LDADD dans Makefile.am disparaîtra. Il n'est pas déraisonnable de s'attendre à ce qu'un utilisateur puisse surcharger LDADD, donc vous devriez certainement vous protéger contre cette situation.

Vos définitions originales de test1_LDADD, ..., test20_LDADD sont beaucoup plus robustes et, autant que je comprends le manuel d'automake, l'utilisation recommandée.

Voir les remarques ici pour plus d'informations: https://www.gnu.org/software/automake/manual/html_node/User-Variables.html https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html