J'ai un projet qui implique des sous-répertoires avec des sous-fabricants. Je suis conscient que je peux passer des variables à partir d'un Makefile parent à un sous-makefile via l'environnement à l'aide de la commande Export. Existe-t-il un moyen de passer des variables d'un sous-makefile à son filet d'appel? C'est à dire. peut exporter des travaux à l'envers? J'ai tenté cela sans succès. Je suppose que la sous-make finit sa coquille est détruite avec ses variables d'environnement. Y a-t-il une autre façon standard de passer des variables vers le haut?
3 Réponses :
La réponse courte à votre question est la suivante: Non, vous ne pouvez pas [directement] faire ce que vous voulez pour une construction récursive em> (voir ci-dessous pour une construction non récursive). faire Exécute un processus de sous-établie comme une ligne de recette comme n'importe quelle autre commande. Son stdout / stardr est imprimé sur le terminal comme n'importe quel autre processus. En général, un sous-processus ne peut affecter l'environnement du parent (évidemment, nous ne parlons pas d'environnement ici, mais le même principe s'applique) - à moins que vous ne construisiez intentionnellement quelque chose comme ça dans le processus parent, mais vous utiliseriez ensuite Mécanismes IPC pour le retirer. P> Il y a un certain nombre de façons que je puisse imaginer pour le tirer, tout ce qui sonne comme une chose affreuse à faire. Par exemple, vous pouvez écrire dans un fichier et la source avec un ... bien que cela doive être dans une cible distincte comme écrite ci-dessus car tous les gmake v4.x a une nouvelle fonctionnalité qui vous permet de Si la commande nécessitait chaque argument d'être sur une ligne distincte de la
Fichier d'entrée, vous pouvez écrire votre recette comme celle-ci: p>
Inclure la directive code> (Remarque: non testée) à l'intérieur d'un eval code>: p> $ (instructions de macro) code> sont évalués avant que la recette commence l'exécution, même si la macro est sur une ligne ultérieure de La recette. p>
include ${SOME_DIRECTORY}/*/makefile
Vous avez raison sur de nombreux points. Je suppose que la question ne se pose pas parce que je tiens au mauvais chemin pour commencer. J'ai décidé de créer une archive des fichiers d'objet dans le sous-makefile et de le lier dans le makefile de niveau supérieur. De cette façon, la commande et les dépendances sont préservées.
C'est une bien meilleure solution.
Votre structure de répertoire ressemble probablement à ceci:
make -C ./dir1 make -C ./dir2
Oui, j'utilise $ (make) -c ./dir1 . Je devinais que le problème était que le processus d'enfant ne pouvait pas mettre à jour l'environnement des parents.
Je pense que la solution la plus simple utilise standard à partir d'un sous-maquefile.
Makefile parent P>
all:
@echo "MessageToTheParent"
Qu'essayez-vous de faire exactement? Vous pourrez peut-être le faire avec une directive Inclure. Sinon, votre seul canal de communication est le système de fichiers.
Vous pourriez faire quelque chose comme ça, mais en règle générale à tout moment, vous devez pirater une caractéristique majeure comme celle-ci, c'est souvent une mauvaise idée.
Un de mes sous-répertoires est un code indépendant du code principal. Il génère plusieurs fichiers d'objets qui doivent être liés au code principal. Ces fichiers d'objet dépendent de l'autre de l'ordre dans lequel ils sont liés. Dans le sous-makefile, j'ai une variable Objs qui contient la liste des fichiers d'objet dans le bon ordre. Je voudrais juste éviter de reconstruire la même liste dans le makefile de niveau supérieur.
Je devrais également mentionner que le sous-répertoire est le code FORTRAN, tandis que le code principal est C ++. Les fichiers d'objet contiennent des emballages à utiliser le code FORTRAN. Je ne pense pas que je puisse résoudre cela avec une directive include, puis-je?
Au départ, j'étais enclin à ne pas voter ceci parce que cela ne semble pas être une chose sage à faire; Cependant, c'est certainement une question à laquelle d'autres peuvent se poser et découvrir que ce n'est pas une bonne idée serait précieuse pour eux.