2009-06-01 9 views
6

J'essaie de coller deux systèmes de construction ensemble. Les deux sont récursifs (les règles du makefile utilisent make pour appeler d'autres makefiles pour construire les composants du projet). Je vais les appeler 'A' et 'B' où 'A' construit l'application et 'B' construit les bibliothèques utilisées par 'A'. Le makefile de niveau supérieur dans A appelle 'make TARGET = quelquechose', ce qui signifie que tous les bits invoqués récursivement de la construction héritent de la valeur de TARGET en tant que variable en lecture seule, y compris le système de construction de B, qui est appelé dans le cadre de la construction récursive. Je ne veux pas que cela se produise dans le système de construction pour 'B' (qui proviennent d'un projet différent) car les makefiles utilisent TARGET pour leurs propres besoins et la construction échoue car TARGET a la mauvaise valeur et est lecture seulement.Comment puis-je ignorer l'affectation de variable de ligne de commande dans une construction récursive?

Je ne vois que deux solutions à cela, dont aucune n'est palettable;

1) Renommez TARGET en quelque chose d'autre dans le makefile de A qui le définit et dans les makefiles de A qui l'utilisent, pour éviter le conflit avec les niveaux inférieurs du système de construction.

2) Utilisez la directive 'override' partout dans les fichiers makefiles dans B où la variable TARGET est définie, pour remplacer son statut en lecture seule.

Quelqu'un a-t-il eu de meilleures idées? - Idéalement, je veux rien à être héritée par le système de construction de B de A, à l'exception des options que je passe explicitement au système de construction B de A.

Soit dit en passant, j'utilise GNU Make V3.80.

+0

Si vous ne voulez pas définir TARGET dans le makefile de B, pourquoi passez-vous TARGET = quoi dans le makefile de A? – JesperE

+0

Le makefile de niveau supérieur passe TARGET = quelquechose à un makefile de deuxième niveau dans A (qui en a besoin) et le makefile de deuxième niveau dans A appelle ensuite le makefile de B, qui hérite de TARGET en tant que variable en lecture seule de l'environnement deuxième niveau. –

Répondre

0

Peut-être que vous pouvez utiliser la directive "unexport" pour empêcher la diffusion de TARGET dans le fichier makefile de B?

+0

Malheureusement, la directive unexport empêche uniquement l'exportation des variables exportées en exportant - elle n'a aucun effet sur les variables passées en ligne de commande au processus make actuel ou héritées de la ligne de commande d'une marque parent. Il semble que la définition d'une valeur via la ligne de commande make la rend indestructible en lecture seule pour toutes les marques enfants. –

+0

Ensuite, je suis à court d'idées. – JesperE

3

Vous pouvez définir MAKEOVERRIDES à rien dans le makefile deuxième niveau A.

callb: 
     cd subdir && $(MAKE) MAKEOVERRIDES= 

Cela passe en bas des paramètres normaux comme commandline -k et -s mais pas commandLine définitions variables .

Ou vous utilisez le Mflags historique qui est le même que MAKEFLAGS sauf Mflags ne contient pas les définitions de variables en ligne de commande.

callb: 
    cd subdir && $(MAKE) $(MFLAGS) 

Détails sur ces deux options peuvent être lues ici: The GNU Make Manual

0

Au point où construire le système A invoque construire le système B, ne pas utiliser « ${MAKE} » directement; invoque un script shell qui appelle le système de construction B (éventuellement après avoir assaini l'environnement).

pour obtenir le comportement où les commandes sont exécutées par « make -n », préfixer la ligne de commande dans le makefile avec « + » (similaire à préfixant la ligne avec « @ » ou « - »).

0

Il semble que vous ayez modifié le makefile A pour invoquer récursivement le makefile B, et donc votre problème. Pourquoi ne pas introduire à la place un nouveau makefile toplevel qui invoque récursivement le makefile B, puis invoque récursivement le makefile A? Par exemple, combined.mk:

all: 
    $(MAKE) -f Makefile.B 
    $(MAKE) -f Makefile.A 

De cette façon, le B makefile hérite rien du makefile.

Questions connexes