Ajout ou assignation conditionnelle Automake pour les sources/flags/libs

Question

Lors de la définition conditionnelle du package/lib _SOURCES ou des indicateurs per-package/lib (CFLAGS, LDFLAGS, LDADD, etc.), est-il préférable de l'ajouter conditionnellement aux indicateurs du package , par exemple:

bin_PPROGRAMS = mypkg 
mypkg_SOURCES = mypkg.c 
if OS1 
mypkg_SOURCES += os1.c 
else 
if OS2 
mypkg_SOURCES += os2.c 
endif 
endif 

ou d'attribuer conditionnellement les variables et concaténer tous dans les drapeaux du paquet (que ce soit peuplé ou nul), par exemple:

if OS1 
os1_src = os1.c 
else 
if OS2 
os2_src = os2.c 
endif 
endif 

bin_PROGRAMS = mypkg 
mypkg_SOURCES = mypkg.c $(os1_src) $(os2_src) 

Je l'ai vu dans les deux sens et je peux voir avantages à chacun. Avec le premier, l'action finale réelle d'ajouter ces drapeaux au paquet est claire dans le conditionnel, et vous n'avez pas encombré la ligne avec des variables qui ne signifient rien dans une construction donnée. Dans ce dernier, ce qui est réellement inclus dans le paquet est consolidé sur une ligne et vous n'avez pas d'appendice invisible qui se passe ailleurs, mais vous ne savez pas vraiment ce qui se passe dans ce nom de variable opaque.

Je suppose qu'une autre option est de faire quelque chose comme l'option 2, mais assignez les variables avec le script configure (configure.ac avec AC_SUBST). Mais j'ai gardé mes scripts configure en détectant uniquement les fonctionnalités disponibles, et en choisissant celles à utiliser dans Makefiles.

L'un d'entre eux présente-t-il un inconvénient technique ou un effet secondaire désagréable?

Answer 1

Les différences que vous observez sont en grande partie une question de style, qui est subjective et donc largement hors-sujet ici. Mais votre vraie question est plutôt objective:

L'un d'entre eux présente-t-il un inconvénient technique ou un effet secondaire désagréable?

Non, dont je suis conscient. Les deux approches fonctionneront bien, au moins de manière isolée. Un contexte plus large pourrait fournir des raisons de préférer les variantes de la seconde approche, telles que la réutilisation des variables conjointement avec plusieurs cibles. Cependant, cela serait plus vraisemblable pour les options de préprocesseur ou de lien que pour le choix des fichiers sources.

---

Personnellement, je structurer le cas particulier que vous avez présenté un peu différemment:

if OS1 
os_src = os1.c 
else 
if OS2 
os_src = os2.c 
endif 
endif 

bin_PROGRAMS = mypkg 
mypkg_SOURCES = mypkg.c $(os_src) 

Certes, cela est une question de style, donc le prendre pour ce qu'il vaut la peine de vous . Ici, l'utilisation de la variable correspond à la structure de la condition: OS1 et OS2 sont alternatives, donc entre eux, ils contrôlent la valeur d'une seule variable. La signification de cette variable est donc plus claire, à la fois au point où sa valeur est fixée et au point où elle est utilisée.

Plusieurs variables ont plus de sens pour plusieurs conditions distinctes, sans rapport.

Answer 2

Je voudrais ajouter quelques modèles plus typiques:

os1_src = os1.c 
os2_src = os2.c 
if OS1 
    myos = os1 
endif 
if OS2 
    myos = os12 
endif 

mypkg_SOURCES = mypkg.c $($(myos)_src) 

autre:

si OS1 OS1 = yes OS2 = pas endif si OS2 OS1 = pas OS2 = yes endif $ (os1) src = os1.c $ (os2) src = os2.c

mypkg_SOURCES = mypkg.c $(yessrc) 

La même approche peut être utilisée pour fournir des indicateurs de construction spécifiques à l'os ou au processeur ou à la configuration. Souvent, certains paramètres communs sont utilisés pour plusieurs modules, tandis que d'autres sont spécifiques à un module. Chaque approche peut être mal utilisée et entraîner des conséquences désastreuses.

Le principal risque est que certains drapeaux ou paramètres d'un module ne soient pas réinitialisés correctement et que certains paramètres d'un autre module se répandent involontairement. Mais aussi, certains modules peuvent manquer un drapeau commun.

Pour réduire ces risques, essayez de vous en tenir à la même technique, même si votre build contient de nombreux modules.