makepp_build_check - En ligne dans le Cloud

PROGRAMME:

Nom

makepp_build_check -- Comment makepp décide de reconstruire les fichiers

DESCRIPTION

A: "architecture_indépendante", E: "correspondance exacte", I: "ignorer_action", O: "seulement_action",
T: "target_newer"

Makepp stocke une variété d'informations sur la façon dont un fichier donné a été créé la dernière fois.
Ces informations incluent la commande de construction, l'architecture et les signatures de tous
les dépendances du fichier. (Toutes les informations stockées sont dans le sous-répertoire .makepp of
chaque répertoire.) Si l'une de ces informations a changé, makepp décide généralement de
reconstruire le fichier. La méthode de vérification de build est ce qui contrôle la décision de makepp de reconstruire.
Il décide quelles informations regarder et lesquelles ignorer.

Makepp sélectionne généralement automatiquement la bonne méthode de vérification de la construction. Cependant, vous pouvez
changer la méthode de signature pour une règle individuelle en utilisant le modificateur :build_check sur le
règle, ou pour toutes les règles d'un makefile en utilisant l'instruction build_check, ou pour tous
makefiles en utilisant l'option de ligne de commande -m ou --build-check-method.

Les données utilisées pour décider d'une reconstruction ou d'un référentiel ou d'une importation de cache de construction sont stockées dans
le fichier d'informations de construction interne. Vous pouvez l'afficher avec makeppinfo, mppi. En dessous de chaque
méthode donne un exemple de la façon de voir ses clés.

Silhouette vérifier méthodes inclus in le pour la distribution
À l'heure actuelle, il existe cinq méthodes de vérification de build incluses dans la distribution :

correspondance exacte
Cette méthode utilise les dates de modification sur le fichier comme signatures. Il reconstruit le
cibles à moins que toutes les conditions suivantes ne soient remplies :

· La signature de chaque dépendance est la même que lors de la dernière version.

· La signature de chaque cible est la même que lors de la dernière version (c'est-à-dire que personne
a joué avec les cibles depuis que makepp les a construites).

· La commande de construction n'a pas changé.

· L'architecture de la machine (ou ce que Perl pense qu'elle est) n'a pas changé.

"exact_match" est la méthode par défaut à moins que vous ne reconstruisiez un Makefile (voir ci-dessous).
C'est un moyen très fiable d'assurer des builds corrects, et c'est presque toujours ce que
vous voulez. Cependant, il a quelques effets secondaires qui peuvent surprendre :

· Si vous avez compilé avec le make traditionnel, puis passez à makepp,
tout est recompilé la première fois que vous exécutez makepp.

· Si vous endommagez les informations de makepp sur ce qui s'est passé lors de la dernière version (par exemple,
vous supprimez le sous-répertoire ".makepp", ou ne le copiez pas lorsque vous copiez tout
else), puis une reconstruction est déclenchée.

· Si vous remplacez un fichier par une ancienne version, une reconstruction est déclenchée. C'est
normalement ce que vous voulez, mais cela peut être surprenant.

· Si vous modifiez un fichier hors du contrôle de makepp (par exemple, vous exécutez le
commande de compilation vous-même), alors makepp reconstruira le fichier la prochaine fois. (Si
vous voulez éviter cela, consultez l'option de ligne de commande "--dont-build".)

· Les fichiers indépendants de l'architecture sont reconstruits lorsque vous passez à un autre
architecture. Ce n'est généralement pas un problème, car ils ne prennent souvent pas longtemps
construire. La raison pour laquelle tous les fichiers sont marqués avec l'architecture, au lieu de
juste des fichiers binaires, c'est que souvent même les fichiers ASCII sont d'architecture-
dépendant. Par exemple, la sortie du programme Solaris "lex" ne sera pas compilée sur
Linux (ou du moins c'était vrai la dernière fois que je l'ai essayé).

Concrètement, un fichier ne sera pas reconstruit, ou peut être récupéré depuis le référentiel ou le build
cache, si la sortie de la commande suivante reste la même, c'est-à-dire correspond aux signatures de
les dépendances :

mppi -k'COMMANDE ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' fichier

architecture_indépendante
La méthode "architecture_independent" est la même que "exact_match" sauf qu'elle ne
pas vérifier l'architecture. Cela peut être utile pour les fichiers indépendants de l'architecture,
qui n'ont pas besoin d'être reconstruites lorsque vous passez à une architecture différente. Pour
exemple, vous n'avez probablement pas besoin de réexécuter "bison" sur Solaris si vous l'avez déjà exécuté sur
Linux.

La méthode "architecture_independent" est mieux utilisée en la spécifiant à l'aide de la
":build_check architecture_independent" modificateur à chaque règle qui produit
fichiers indépendants de l'architecture. Makepp par défaut ne suppose jamais que les fichiers sont
indépendant de l'architecture, car même .c les fichiers peuvent dépendre de l'architecture. Pour
exemple, la sortie de Solaris lex ne sera pas compilée sous Linux, ou du moins elle
ne serait pas la dernière fois que j'ai essayé. Vous devez donc spécifier manuellement cette méthode de vérification de construction pour
tous les fichiers qui sont vraiment indépendants de l'architecture.

Concrètement, un fichier ne sera pas reconstruit, ou peut être récupéré depuis le référentiel ou le build
cache, si la sortie de la commande suivante reste la même, c'est-à-dire correspond aux signatures de
les dépendances :

mppi -k'COMMAND SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' fichier

ignorer_action
La méthode "ignore_action" est la même que "exact_match" sauf qu'elle ne vérifie pas
la chaîne d'action (la commande). Parfois, une commande peut changer et vous ne voulez pas
forcer une reconstruction.

Par exemple, vous voudrez peut-être mettre explicitement une date dans votre commande pour vous connecter lorsque le
build a été fait, mais vous ne voulez pas forcer une reconstruction à chaque fois que la commande est
réalisé. Par exemple,

BUILD_DATE := $(date du shell)

mon_programme : $(MODULES).o
$(CXX) $(entrées) -DBUILD_DATE="\"$(BUILD_DATE)\"" date_stamp.c -o $(sortie)

Cela compilera date_timbre.c avec l'horodatage de la dernière génération, mais ne forcera pas un
recompiler lorsque la date change. Malheureusement, si quelque chose d'autre sur le lien
changements de commande (par exemple, vous modifiez les options de l'éditeur de liens), cela ne déclenchera pas non plus de reconstruction.

Ceci est également utile en conjonction avec le $(changed_inputs) ou $? variable pour
actions qui mettent simplement à jour une cible, plutôt que de la reconstruire à partir de zéro. Pour
exemple, vous pouvez mettre à jour un fichier .a comme ceci :

libmine.a : *.o : build_check ignore_action
$(AR) ru $(sortie) $(entrées_modifiées)

Cela fonctionnera toujours la plupart du temps si vous oubliez de spécifier le " : build_check
ignore_action". Cependant, supposons qu'aucun des fichiers .o n'ait changé. La commande
sera désormais "ar ru libmine.a" qui est probablement différent de ce qu'il était la dernière fois
(par exemple, "ar ru libmine.a buggy_module.o"), makepp exécutera donc la commande. Dans ce
cas, la commande ne fera rien d'autre que perdre du temps.

Construire des fichiers .a comme celui-ci est déconseillé, car cela peut laisser des fichiers .o obsolètes à l'intérieur
les archives. Si vous supprimez un fichier source, le fichier .o est toujours dans le fichier .a,
et cela peut conduire à des builds incorrects. Il est préférable de créer un fichier .a comme celui-ci :

libmine.a : *.o
&rm $(sortie)
$(AR) ru $(sortie) $(entrées)

Concrètement, un fichier ne sera pas reconstruit, ou peut être récupéré depuis le référentiel ou le build
cache, si la sortie de la commande suivante reste la même, c'est-à-dire correspond aux signatures de
les dépendances :

mppi -k'ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' fichier

cible_nouveau
La méthode "target_newer" ne regarde que la date du fichier. Si une dépendance est plus
récente que la cible, la cible est reconstruite. C'est l'algorithme que le
Unix traditionnel a prendre une usages utilitaires.

La méthode "target_newer" n'est pas aussi sûre que la méthode "exact_match" car elle ne
déclencher une reconstruction si vous modifiez la commande build, ou si vous remplacez un fichier par un
Ancienne version. Parfois aussi, il peut être confus si les horloges ne sont pas correctement
synchronisé. Par exemple, si un fichier obtient d'une manière ou d'une autre la date du 4 juin 2048, alors
d'ici 2048, chaque fichier qui dépend de ce fichier sera reconstruit même si
le fichier ne change pas. De plus, le passage à une architecture différente ne déclenchera pas de
reconstruire. Cela empêche de récupérer la cible d'une règle à partir d'un cache de build, car il n'y a pas
signature unique qui peut être associée à l'ensemble infini de paires remplissant les
relation plus récente que.

Mais il y a quelques cas où vous voudrez peut-être utiliser la méthode "target_newer":

· Lorsqu'il est raisonnable pour un utilisateur de créer un fichier hors du contrôle de makepp.
L'exemple le plus courant est peut-être les commandes qui génèrent le makefile
lui-même, c'est-à-dire la procédure d'autoconfiguration. Les utilisateurs émettent généralement le fichier configure
commande manuellement, mais les makefiles ont souvent un moyen de se mettre à jour
automatiquement. Dans ce cas, nous ne voulons pas forcer le makefile à reconstruire
lui-même si l'utilisateur a tapé la commande manuellement, donc la méthode "target_newer" est
plus appropriée que la méthode "exact_match". En fait, si makepp essaie de
construire un makefile, il fait de "target_newer" la méthode par défaut jusqu'à ce qu'il soit terminé
construire le makefile.

· Quand il est raisonnable pour un utilisateur de modifier un fichier après que makepp l'a construit. Pour
exemple, si un fichier n'existe pas, vous pouvez vouloir le copier à partir d'un
l'emplacement, ou l'extraire d'un référentiel ; mais l'utilisateur doit être autorisé à
le modifier. Si vous utilisez la méthode de vérification de compilation "exact_match" par défaut, makepp
détecter que l'utilisateur a modifié le fichier et donc il forcera une nouvelle copie de
l'emplacement central ou une nouvelle caisse, effaçant les modifications de l'utilisateur.

Si vous devez vérifier manuellement les horodatages, consultez les exemples makeppinfo pour savoir comment obtenir
le chemin de chaque dépendance.

seule_action
La méthode très spécifique "only_action" n'exécutera l'action que si la commande
chaîne diffère de la dernière fois qu'il a été exécuté. Par exemple,

$(RACINE)/include/%.h : %.h
&ln -fr $(entrée) $(sortie)

publie un fichier, mais ne le répète pas lorsque le fichier change. Notez que le &ln
La commande est intégrée et donc bon marché, mais makepp doit toujours débourser et surveiller un
processus pour effectuer l'ensemble de l'action. Donc, si vous avez beaucoup de fichiers à publier, il
est toujours un avantage. En fait, nous n'avons pas précisé la méthode, car, lorsque la cible
est un lien symbolique, cette vérification de build est utilisée automatiquement. Vous n'avez qu'à
spécifiez-le pour d'autres commandes qui dépendent uniquement de la commande (qui généralement
contient les noms des entrées):

%.list : %.x : build_check only_action
&écho $(entrées) -o $(sortie)

Concrètement, un fichier ne sera pas reconstruit, ou peut être récupéré depuis le référentiel ou le build
cache, si la sortie de la commande suivante reste la même, c'est-à-dire correspond aux signatures de
les dépendances :

mppi -kCOMMAND fichier

D'autres méthodes de vérification de build sont possibles. Vous pouvez écrire votre propre méthode de vérification de construction en
créer un module "Mpp::BuildCheck::MyMethod". Lire la documentation dans
Mpp/BuildCheck.pm dans la distribution makepp. Très probablement, vous voudrez votre contrôle de construction
pour hériter de "Mpp::BuildCheck::exact_match", alors lisez aussi sa documentation.

Il est plus souvent utile de modifier le mécanisme de signature que de modifier le contrôle de construction
mécanisme directement. Avant de modifier le mécanisme de vérification de build, voyez si votre problème est
mieux servi en changeant les signatures (voir makepp_signatures pour plus de détails).

Voici quelques raisons pour lesquelles une méthode de vérification de build personnalisée peut être utile :

· Si vous voulez que makepp ignore une partie de la commande. Par exemple, si vous avez des commandes
dans votre makefile comme ceci :

xo : xc
ssh $(REMOTE_MACHINE) cc $< -o $@

vous voudrez peut-être que makepp ne force pas une reconstruction si "$(REMOTE_MACHINE)" change. Tu
pourrait modifier la méthode "exact_match" afin qu'elle connaisse les commandes ssh et ignore le
nom de la machine. Vérifiez :dispatch pour une autre façon d'y parvenir.

Utilisez makepp_build_check en ligne à l'aide des services onworks.net