Comment forcer un makefile à reconstruire une cible

J'ai un makefile qui construit puis appelle un autre makefile. Puisque ce makefile appelle plus de makefiles qui font le travail, il ne change pas vraiment. Ainsi, il continue de penser que le projet est construit et à jour.

dnetdev11 ~ # make
make: `release' is up to date.

Comment forcer le makefile à reconstruire la cible?

clean = $(MAKE) -f ~/xxx/xxx_compile.workspace.mak clean


build = svn up ~/xxx                                                       \
        $(clean)                                                                \
        ~/cbp2mak/cbp2mak -C ~/xxx ~/xxx/xxx_compile.workspace        \
        $(MAKE) -f ~/xxx/xxx_compile.workspace.mak $(1)                    \


release:
        $(build )

debug:
        $(build DEBUG=1)

clean:
        $(clean)

install:
        cp ~/xxx/source/xxx_utility/release/xxx_util /usr/local/bin
        cp ~/xxx/source/xxx_utility/release/xxxcore.so /usr/local/lib

Remarque: les noms ont été supprimés pour protéger les innocents

Edit: Version finale fixe:

clean = $(MAKE) -f xxx_compile.workspace.mak clean;


build = svn up;                                         \
        $(clean)                                        \
        ./cbp2mak/cbp2mak -C . xxx_compile.workspace;   \
        $(MAKE) -f xxx_compile.workspace.mak    $(1);   \


.PHONY: release debug clean install

release:
        $(call build,)

debug:
        $(call build,DEBUG=1)

clean:
        $(clean)

install:
        cp ./source/xxx_utillity/release/xxx_util /usr/bin
        cp ./dlls/Release/xxxcore.so /usr/lib

Vous pouvez déclarer qu'une ou plusieurs de vos cibles sont fausses .

Une cible bidon est une cible qui n'est pas vraiment le nom d'un fichier; il s'agit plutôt d'un nom pour une recette à exécuter lorsque vous faites une demande explicite. Il y a deux raisons d'utiliser une cible bidon: pour éviter un conflit avec un fichier du même nom, et pour améliorer les performances.

...

Une cible bidon ne doit pas être une condition préalable à un vrai fichier cible; si c'est le cas, sa recette sera exécutée chaque fois que make va mettre à jour ce fichier. Tant qu'une cible bidon n'est jamais une condition préalable d'une cible réelle, la recette cible bidon ne sera exécutée que lorsque la cible bidon est un objectif spécifié

Le -Bcommutateur à faire, dont la forme longue est --always-make, indique makede ne pas tenir compte des horodatages et de créer les cibles spécifiées. Cela peut aller à l'encontre de l'objectif de l'utilisation de make, mais c'est peut-être ce dont vous avez besoin.

Une astuce qui était autrefois documentée dans un manuel Sun pour makeest d'utiliser une cible (inexistante) '.FORCE'. Vous pouvez le faire en créant un fichier, force.mk, qui contient:

.FORCE:
$(FORCE_DEPS): .FORCE

Ensuite, en supposant que votre makefile existant est appelé makefile, vous pouvez exécuter:

make FORCE_DEPS=release -f force.mk -f makefile release

Puisqu'il .FORCEn'existe pas, tout ce qui en dépend sera obsolète et reconstruit.

Tout cela fonctionnera avec n'importe quelle version de make; sous Linux, vous avez GNU Make et pouvez donc utiliser la cible .PHONY comme indiqué.

Il convient également makede se demander pourquoi la publication est à jour. Cela peut être dû au fait que vous avez une touch releasecommande parmi les commandes exécutées; cela peut être dû au fait qu'il existe un fichier ou un répertoire appelé «release» qui existe et qui n'a pas de dépendances et qui est donc à jour. Ensuite, il y a la vraie raison ...

Quelqu'un d'autre a suggéré .PHONY, ce qui est tout à fait correct. .PHONY doit être utilisé pour toute règle pour laquelle une comparaison de date entre l'entrée et la sortie n'est pas valide. Puisque vous n'avez aucune cible du formulaire, output: inputvous devez utiliser .PHONY pour TOUS!

Cela dit, vous devriez probablement définir quelques variables en haut de votre makefile pour les différents noms de fichiers, et définir de vraies règles make qui ont à la fois des sections d'entrée et de sortie afin que vous puissiez utiliser les avantages de make, à savoir que vous ne compilerez réellement les choses qui sont nécessaires pour faire face!

Edit: exemple ajouté. Non testé, mais voici comment vous faites .PHONY

.PHONY: clean    
clean:
    $(clean)

Cette technique simple permettra au makefile de fonctionner normalement lorsque le forçage n'est pas souhaité. Créez une nouvelle cible appelée force à la fin de votre makefile . La cible de force touchera un fichier dont dépend votre cible par défaut. Dans l'exemple ci-dessous, j'ai ajouté touch myprogram.cpp . J'ai également ajouté un appel récursif à faire . Cela entraînera la création de la cible par défaut à chaque fois que vous tapez make force .

yourProgram: yourProgram.cpp
       g++ -o yourProgram yourProgram.cpp 

force:
       touch yourProgram.cpp
       make

Si je me souviens bien, «make» utilise des horodatages (heure de modification du fichier) pour déterminer si une cible est à jour ou non. Une manière courante de forcer une reconstruction est de mettre à jour cet horodatage à l'aide de la commande «touch». Vous pouvez essayer d'appeler 'touch' dans votre makefile pour mettre à jour l'horodatage de l'une des cibles (peut-être l'un de ces sous-makefiles), ce qui pourrait forcer Make à exécuter cette commande.

J'ai essayé ça et ça a marché pour moi

ajoutez ces lignes à Makefile

clean:
    rm *.o output

new: clean
    $(MAKE)     #use variable $(MAKE) instead of make to get recursive make calls

enregistrer et appeler maintenant

make new 

et il recompilera tout à nouveau

Qu'est-il arrivé?

1) «nouveaux» appels propres. «clean» fait «rm» qui supprime tous les fichiers objets qui ont l'extension «.o».

2) «nouveaux» appels «faire». 'faire' voir qu'il n'y a pas de fichiers '.o', donc il crée à nouveau tous les '.o'. puis l'éditeur de liens relie tout le fichier .o à une sortie exécutable

Bonne chance

Selon Miller's Recursive Make Considered Harmful, vous devriez éviter d'appeler $(MAKE)! Dans le cas que vous montrez, c'est inoffensif, car ce n'est pas vraiment un makefile, juste un script wrapper, qui aurait tout aussi bien pu être écrit dans Shell. Mais vous dites que vous continuez comme ça à des niveaux de récursion plus profonds, donc vous avez probablement rencontré les problèmes indiqués dans cet essai révélateur.

Bien sûr, avec GNU, c'est difficile à éviter. Et même s'ils sont conscients de ce problème, c'est leur façon documentée de faire les choses.

OTOH , makepp été créé pour résoudre ce problème. Vous pouvez écrire vos makefiles au niveau de chaque répertoire, mais ils sont tous rassemblés dans une vue complète de votre projet.

Mais les makefiles hérités sont écrits de manière récursive. Il existe donc une solution de contournement où $(MAKE)ne fait rien d'autre que canaliser les sous-requêtes vers le processus makepp principal. Seulement si vous faites des choses redondantes ou, pire, contradictoires entre vos soumissions, vous devez demander --traditional-recursive-make(ce qui brise bien sûr cet avantage de makepp). Je ne connais pas vos autres makefiles, mais s'ils sont écrits proprement, avec makepp, les reconstructions nécessaires devraient se produire automatiquement, sans avoir besoin de hacks suggérés ici par d'autres.

Cela a déjà été mentionné, mais je pensais pouvoir ajouter à l'utilisation touch

Si vous avez touchtous les fichiers source à compiler, la touchcommande modifie les horodatages d'un fichier à l'heure système à laquelle la touchcommande a été exécutée.

L'horodatage du fichier source est ce qui permet makede "savoir" qu'un fichier a changé et doit être recompilé

Par exemple: si le projet était un projet C ++, alors faites touch *.cpp, puis réexécutez makeet make devrait recompiler l'ensemble du projet.

Si vous n'avez pas besoin de conserver l'une des sorties que vous avez déjà compilées avec succès

nmake /A 

reconstruit tout

Cela dépend en fait de la cible. S'il s'agit d'une cible bidon (c'est-à-dire que la cible n'est PAS liée à un fichier), vous devez la déclarer comme .PHONY.

Si toutefois la cible n'est pas une cible bidon mais que vous voulez simplement la reconstruire pour une raison quelconque (un exemple est lorsque vous utilisez la macro de prétraitement __TIME__), vous devez utiliser le schéma FORCE décrit dans les réponses ici.

http://www.gnu.org/software/make/manual/html_node/Force-Targets.html#Force-Targets

Comme l'a souligné Abernier, il existe une solution recommandée dans le manuel GNU make, qui utilise une `` fausse '' cible pour forcer la reconstruction d'une cible:

clean: FORCE
        rm $(objects)
FORCE: ; 

Cela fonctionnera propre, quelles que soient les autres dépendances.

J'ai ajouté le point-virgule à la solution du manuel, sinon une ligne vide est requise.

Sur mon système Linux (Centos 6.2), il y a une différence significative entre déclarer la cible .PHONY et créer une fausse dépendance sur FORCE, lorsque la règle crée en fait un fichier correspondant à la cible. Lorsque le fichier doit être régénéré à chaque fois, il a fallu à la fois la fausse dépendance FORCE sur le fichier et .PHONY pour la fausse dépendance.

faux:

date > $@

droite:

FORCE
    date > $@
FORCE:
    .PHONY: FORCE

make clean supprime tous les fichiers objets déjà compilés.