Méfiez-vous des recettes comme celle-ci
target:
MY_ID=$(GENERATE_ID);
echo $MY_ID;
Cela fait deux choses mal. La première ligne de la recette est exécutée dans une instance de shell distincte de la deuxième ligne. La variable est perdue entre-temps. La deuxième chose qui cloche, c'est que le $
n'est pas échappé.
target:
MY_ID=$(GENERATE_ID); \
echo $$MY_ID;
Les deux problèmes ont été corrigés et la variable est utilisable. La barre oblique inverse combine les deux lignes pour s'exécuter dans un seul shell, d'où le réglage de la variable et la lecture des mots de passe variables, fonctionne.
Je me rends compte que le message d'origine disait comment obtenir les résultats d'une commande shell dans une variable MAKE, et cette réponse montre comment l'obtenir dans une variable shell. Mais d'autres lecteurs pourraient en bénéficier.
Une dernière amélioration, si le consommateur s'attend à ce qu'une "variable d'environnement" soit définie, alors vous devez l'exporter.
my_shell_script
echo $MY_ID
aurait besoin de cela dans le makefile
target:
export MY_ID=$(GENERATE_ID); \
./my_shell_script;
J'espère que cela aide quelqu'un. En général, il faut éviter de faire un vrai travail en dehors des recettes, car si quelqu'un utilise le makefile avec l'option '--dry-run', pour SEULEMENT voir ce qu'il fera, il n'aura pas d'effets secondaires indésirables. Chaque $(shell)
appel est évalué au moment de la compilation et certains travaux réels pourraient accidentellement être effectués. Mieux vaut laisser le vrai travail, comme générer des identifiants, à l'intérieur des recettes lorsque cela est possible.