makepp_rules - En ligne dans le Cloud

PROGRAMME:

Nom

makepp_rules -- Comment dire à makepp de construire quelque chose

DESCRIPTION

?: &,
-,
@, B: :build_cache,
:build_check, D: :envoi, E: :env, I: "ignorer_erreur",
:comprendre, L: :dernière chance, M: makeperl, N: "noecho", P: :analyseur,
"perle", S: :Signature

Une règle indique à makepp comment créer un fichier ou une classe de fichiers. Makepp prend en charge le
même syntaxe de règle que les autres implémentations de make, plus quelques ajouts qui lui sont propres.

Une règle a le format général

expression_cible : expression_dépendance [ : arguments facultatifs]
actes

La liste des cibles ne peut contenir aucune variable automatique (sauf "$(foreach)"). Les
la liste de dépendances peut contenir uniquement des variables automatiques se référant à la cible (c'est-à-dire,
"$(output)", "$(outputs)", ou leurs synonymes). L'action peut contenir n'importe quel
variables.

Si makepp décide que la règle doit être exécutée, chaque ligne de la règle est exécutée
séquentiellement, et si un retourne un statut différent de zéro, les autres ne sont pas exécutés (et
makepp s'interrompt avec une erreur à moins que vous n'ayez spécifié l'option "-k" sur la ligne de commande.)
Chaque action doit être sur une seule ligne. Si une action est trop longue pour être écrite commodément sur un
une seule ligne, vous pouvez le diviser en plusieurs lignes et mettre une barre oblique inverse pour indiquer que le
plusieurs lignes doivent être combinées en une seule.

Afin de distinguer les actions de la règle suivante, l'action doit être plus en retrait
que la ligne contenant les cibles et les dépendances. Contrairement à d'autres implémentations de
make, makepp ne se soucie pas vraiment de combien vous l'indentez ou si vous utilisez des caractères de tabulation
plutôt que des espaces. Pour conserver la rétrocompatibilité avec les marques traditionnelles, les règles
makepp utilise pour décider quand les actions se terminent et quand la règle suivante commence sont quelque peu compliquées :

· La première ligne d'action doit être plus indentée que la ligne contenant la cible.

· Si une ligne est indentée d'un caractère de tabulation ou de 8 espaces ou plus, alors elle est considérée
une ligne d'action.

· Une ligne vide ou une ligne de commentaire avec le caractère "#" dans la marge de droite termine le
règle, à moins que la prochaine ligne non vide soit en retrait de plus de 8 espaces (ou plus d'un
languette).

· Si une ligne est indentée autant ou plus que la première ligne d'action, alors elle est
considéré comme une ligne d'action supplémentaire.

Il y a quelques actions spéciales :

& Ce symbole doit être suivi d'un nom de commande et d'un nombre quelconque d'arguments. Coquille
la syntaxe n'est pas entièrement comprise ici, seuls les guillemets simples et doubles et les barres obliques inverses
personnages à l'intérieur, comme tout au long de makepp. Le nom de la commande mène soit à une fonction
"c_Nom" à appeler avec les chaînes restantes comme arguments. Si une telle fonction peut
introuvable, cela revient à appeler "run" à partir d'un bloc "perl".

Cela permet d'appeler efficacement une commande intégrée, fournie par makefile ou externe.
Le préfixe "&" a été choisi car c'est l'invocateur de fonction en Perl, et parce que
au début, c'est illégal dans Shell.

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

noécho
@ Normalement, chaque commande shell est affichée au fur et à mesure de son exécution. Cependant, si le premier mot
de l'action est "noecho" (ou si elle commence par le caractère "@"), alors la commande
n'est pas imprimé. Par exemple,

%.o : %cxx
noecho $(LIBTOOL) --mode=compile $(CC) -c $(entrée)

Cela signifie que lorsque la commande libtool est exécutée, elle n'est pas imprimée. (Libtool
lui-même imprime généralement la commande modifiée qu'il exécute, il est donc redondant de
imprimez-le deux fois.)

ignorer_erreur
- Normalement, si la commande shell renvoie un état différent de zéro, makepp s'interrompt car
la commande a échoué. Cependant, certains programmes définissent de manière incorrecte l'état à la sortie, ou
il peut y avoir une erreur qui n'est vraiment pas fatale et ne devrait pas annuler l'ensemble
compilation. Vous pouvez faire en sorte que makepp ignore le statut de retour en spécifiant
"ignore_error" comme premier mot de la ligne de commande (ou "-" comme premier caractère).
Par exemple,

$(distribution bidon) :
ignore_error rm -r my_program-$(VERSION) # Se débarrasser des fichiers indésirables précédents.
&mkdir mon_programme-$(VERSION)
&cp $(FILES) mon_programme-$(VERSION)
tar cf mon_programme-$(VERSION).tar mon_programme-$(VERSION)

Cette commande crée un répertoire, y copie un tas de fichiers, puis met
tout dans un fichier tar pour la distribution. C'est une bonne idée de nettoyer le
contenu précédent du répertoire, s'il y avait quelque chose auparavant, et c'est
ce que fait la première ligne. Le "rm" peut échouer, mais son état de retour est ignoré.

perl
maquillage
C'est essentiellement la même chose que l'instruction perl, mais elle est exécutée à chaque fois que
exécuter la règle, pas lors de la lecture du makefile. La première variante est simple Perl
code, tandis que la deuxième variante passe d'abord l'instruction via la variable de style Make
vous propose d’explorer.

Pour les deux possibilités de mettre les bretelles du corps, voir l'explication à
"perl_perlcode" dans makepp_statements. Notez que la troisième variante y est expliquée
n'a aucun sens ici, car toutes les lignes d'action doivent être en retrait. Vous devez signaler
échec dans les instructions Perl, en appelant "die".

Par règle, les instructions Perl sont actuellement évaluées dans un sous-processus commun, sauf sur
Les fenêtres. Cela signifie qu'ils n'ont qu'un accès en lecture à toutes les variables makefile. C'est aussi
le processus qui exécute des actions non Perl. Donc appeler exec ou exit va confondre
makepp. Mais cela peut changer à l'avenir. Pour un moyen efficace d'appeler Perl
scripts, voir l'élément précédent "&" ou "run".

$(version bidon) :
noecho perl {{ # $(cible) & $(VERSION) de Perl :
print "Ceci est ".f_target()." $VERSION\n" ;
}}
echo Vous pouvez mélanger cela avec les commandes Shell
-makeperl { print "Ceci est $(cible) $(VERSION)\n" }

Il existe plusieurs types de règles, chacune ayant des objectifs différents.

Explicite Règles
cible1 cible2 : dépendance1 dépendance2 ...
actions à effectuer

Cette syntaxe précise que pour faire soit target1 or target2, tous les fichiers
dépendance1, dépendance2, etc., doit déjà avoir été fait. Ensuite, les actions données sont
exécuté par le shell pour faire les cibles.

La première règle explicite dans un fichier est la cible par défaut et est établie si vous ne spécifiez pas
toutes les cibles sur la ligne de commande.

Contrairement aux programmes make traditionnels, makepp suppose généralement qu'une invocation de l'action
fait toutes les cibles (sauf s'il n'y a pas de dépendances). Par exemple, une invocation
de yacc crée les deux fichiers de sortie pour cette règle :

y.tab.c y.tab.h : analyseur.y
$(YACC) -d analyseur.y

Notez que les autres implémentations de make n'ont pas de concept de commande unique
produisant plusieurs fichiers de sortie, et ainsi, lorsque vous spécifiez plusieurs cibles, elles
exécuter la règle une fois par cible. Makepp reviendra à ce comportement s'il ressemble à
il s'agit d'un makefile à l'ancienne. Plus précisément, il exécutera la règle une fois par cible,
au lieu d'une seule fois dans l'ensemble, si toutes les conditions suivantes sont vraies :

· L'action de la règle mentionne la variable automatique $@. (Les synonymes "$(output)" ou
"$(target)" ne déclenche pas ce comportement.)

· L'action de la règle ne mentionne pas la variable automatique "$(outputs)" (ou son synonyme
"$(cibles)").

· Ce n'est pas une règle de modèle, et il n'y a pas de clause foreach.

Par exemple,

tous les tests d'installation :
pour le sous-répertoire dans $(SUBDIRS); faire cd $$subdir && $(MAKE) $@; cd ..; terminé

est un idiome courant dans les makefiles, et makepp le prend en charge. (Notez que vous ne devez jamais utiliser
make récursif dans tous les nouveaux makefiles que vous écrivez - utilisez l'instruction "load_makefile", ou
chargement implicite du makefile à la place.)

Si vous voulez que la même règle soit exécutée une fois pour chaque cible (par exemple, parce que les cibles
ont des commandes similaires), il est préférable d'utiliser soit une règle de modèle (voir ci-dessous) soit un
clause "foreach". Par exemple, si avec un programme make traditionnel vous écriviez :

a B c d:
faire_quelque chose à construire $@ > $@

dans makepp, vous voudriez probablement l'écrire comme ceci :

$(foreach) : : foreach abcd
do_something à construire $(output) > $(output)

Faux objectifs

A faux l'objectif est une cible qui n'existera jamais réellement dans le système de fichiers ; c'est juste un
moyen de faire en sorte que makepp construise des cibles et exécute éventuellement des commandes supplémentaires.

Une cible bidon typique est "tout", qui est généralement utilisé pour provoquer tout ce qui peut être
construit pour être construit, comme ceci :

tous : prog1 prog2 sous-répertoire/prog3 sous-répertoire2/libmine.a
@&echo "C'est fini !"

Si vous tapez "makepp all", ou si vous mettez all comme première cible explicite dans votre makefile
(ce qui est typique) et tapez simplement "makepp", alors toutes les dépendances seront
construit, alors il affichera "Tout est fait!". À ce stade, makepp recherchera le fichier ./tous
et découvrira qu'il n'existe pas. Il va se plaindre bruyamment.

Pour empêcher makepp d'attendre le fichier ./tous pour sortir, vous devez lui dire que c'est un
cible bidon. Il suffit de mettre une ligne comme celle-ci dans votre makefile (ça ne change rien
où):

.PHONY : tous

Une alternative équivalente qui est parfois plus pratique consiste à utiliser le "$(phony )"
fonction, comme ceci:

$(phony all) : prog1 prog2 subdir/prog3 subdir2/libmine.a

Les cibles bidon dans un makefile peuvent faire référence à des cibles bidon dans un autre makefile. C'est
souvent fait avec la cible "propre", comme ceci :

# Makefile de niveau supérieur :
# beaucoup de règles et de choses ici
#....
$(phony clean) : sous-répertoire1/nettoyer sous-répertoire2/nettoyer
&rm -fm mon_programme

Ensuite, dans les sous-répertoires, les makefiles peuvent se lire comme ceci :

# Makefile dans un sous-répertoire
#...
$(faux nettoyage) :
&rm -fm $(caractère générique *.o *.a)

Mais de nos jours, vous utiliseriez la commande "makeppclean", au lieu d'une cible propre.

Wildcards

Il est prudent de spécifier des caractères génériques dans la liste des dépendances. Les caractères génériques correspondent non seulement aux fichiers
qui existent, mais des fichiers qui peuvent être créés compte tenu des règles du makefile. Par exemple,
pour construire une bibliothèque à partir de tous les fichiers .o d'un répertoire, vous pouvez écrire ceci :

libmine.a : *.o
&rm -f $(sortie)
ar cr $(sortie) $(entrées)

Cela fonctionnera même si aucun des fichiers ".o" n'a encore été créé, car makepp's
les caractères génériques correspondent à des fichiers qui n'existent pas encore mais peuvent être construits. Cela va même ramasser
fichiers dont la règle est découverte plus tard (dans le même makefile, ou pas encore lu). Dans ce
dernier point elle diffère de la fonction "wildcard", qui se limite aux règles connues,
car il doit retourner son résultat lorsqu'il est développé.

Makepp prend en charge tous les caractères génériques de shell habituels ("*", "?" et "[]"). Il a également un
joker "**" qui correspond à un nombre quelconque de répertoires intermédiaires. (Cette idée a été volée
de zsh.) Par exemple, "**/*.c" correspond à tous les .c fichiers dans toute l'arborescence des sources.
"objects/**/*.o" correspond à tous les .o fichiers contenus n'importe où dans le sous-répertoire objets
ou l'un de ses sous-répertoires ou l'un de leurs sous-répertoires. Le caractère générique "**" ne
suivez des liens symboliques vers des répertoires à n'importe quel niveau. Il ne renverra jamais non plus de fausses cibles.

Les caractères génériques de Makepp ignoreront les fichiers ou répertoires qui existent mais ne peuvent pas être lus. Après
tous, ces fichiers ne peuvent pas être utilisés dans le processus de construction de toute façon. Mettre des fichiers illisibles dans un
répertoire est principalement utile pour empêcher l'importation automatique du fichier donné à partir d'un
dépôt.

L'affirmation initiale était que c'est sûr. C'est dans le sens où cela fonctionne si
les fichiers existent déjà ou doivent d'abord être créés. Cependant, il est dangereux dans le sens
qu'il correspondra toujours aux fichiers qui ont été construits par makepp, mais n'ont plus de règle (par exemple
vous avez supprimé le .c fichier, mais le .o est toujours là.) Pour éviter cela, utilisez le
Option "--rm-vicié".

Patron de Couture
Une règle de modèle est une règle qui est appliquée sur la base d'un modèle textuel. Ceci est utilisé pour
appliquer la même règle à toute une classe de fichiers. La syntaxe est la même que celle de GNU make
règles de modèle :

%.o : %c
$(CC) -c $(entrée) -o $(sortie)

Cela dit que tout fichier dans le répertoire actuel qui correspond à "*.c" peut être converti en
le fichier .o correspondant à l'aide de la commande donnée.

Notez que plusieurs dépendances de modèle peuvent être fournies. Par exemple, si votre xyz.o filet
dépend du correspondant xyz.cpp fichier, et aussi sur un fichier appelé moc_xyz.cflags qui
contient les options du compilateur, cela pourrait être exprimé avec :

%.o : %cpp %.cflags
$(CXX) `cat $(stem).cflags` -c $(entrées) -o $(sortie)

Vous pouvez également avoir plusieurs cibles de modèle. Par exemple,

%.tab.h %.tab.c : %.y
yacc -d $(entrée)
&mv y.tab.h $(stem).tab.h
&mv y.tab.c $(stem).tab.c

Normalement, les règles de modèle ne recherchent que les fichiers dans les répertoires actuels. Vous pouvez forcer
pour rechercher dans le répertoire actuel et tous les répertoires en dessous en définissant

makepp_percent_subdirs := 1

avant la première règle de modèle dans votre makefile ou sur la ligne de commande par exemple.

Il y a une nette différence entre "%" et le caractère générique "*", bien que les deux correspondent à n'importe quel
chaîne : le caractère générique renvoie une liste de fichiers entièrement utilisés à ce stade. Donc
cela dépend de tout .o fichiers constructibles ici :

programme : *.o
$(LD) $(LDFLAGS) $(entrées) -o $(sortie)

Cela n'a pas pu être réalisé en remplaçant "*" par "%", car ce dernier est pour un par un
correspondance de l'entrée à la sortie, produisant en interne une règle pour chaque tige correspondante.

Statique modèle
Une règle de modèle statique est une règle de modèle qui s'applique uniquement à un ensemble limité de fichiers :

$(SPECIAL_MODULES).o : %.o : %.cpp
$(CXX) -c $(entrée) -o $(sortie)

Cela dit que la règle de modèle s'applique uniquement aux fichiers dans "$(SPECIAL_MODULES).o".

C'est principalement pour la compatibilité avec GNU make ; les règles foreach (voir ci-dessous) sont plus
moyen puissant de faire la même chose.

Pour chaque
La syntaxe de règle de modèle ci-dessus est suffisamment puissante pour prendre en charge presque toutes les versions, mais
il est parfois nécessaire de faire quelque chose de plus compliqué. Makepp fournit un plus
syntaxe puissante : la clause ":foreach" pour la règle.

expression_cible : expression_dépendance : pour chaque liste de fichiers
actes

Le type de règle foreach le plus simple est juste une règle de modèle dont l'application est restreinte
à une liste spécifique de fichiers. Par exemple, supposons que vous ayez une règle de régularité qui indique
makepp comment compiler tout .c des dossiers. Cependant, vous avez une liste de .c fichiers pour lesquels vous
veux faire quelque chose de différent. Tu pourrais faire quelque chose comme ça :

# Voici la règle qui s'applique à tout :
%.o : %.c
$(CC) $(CFLAGS) -c $(entrée) -o $(sortie)

%.o : %.c : pour chaque $(SPECIAL_MODULES)
$(CC) $(SPECIAL_CFLAGS) -c $(entrée) -o $(sortie)

Une utilisation encore plus puissante des règles foreach profite du fait que la variable
"$(foreach)" est défini à tour de rôle sur chaque fichier correspondant à la liste de fichiers et à la cible et
les expressions de dépendance sont évaluées. La liste de fichiers peut contenir des caractères génériques, et ces
faire correspondre même des fichiers qui n'existent pas encore mais qui peuvent être construits (voir "Wildcards" dans
makepp_rules).

C'est une syntaxe lourde mais elle est extrêmement flexible, car la variable "$(foreach)"
peut apparaître de quelque manière que ce soit dans l'expression. Tout d'abord, notez que les règles de modèle sont en fait un
cas particulier des règles foreach ; la règle du modèle

%.o : %.c
$(CC) $(CFLAGS) -c $(entrée) -o $(sortie)

est exactement équivalent à :

$(patsubst %.c, %.o, $(foreach)) : $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(entrée) -o $(sortie)

(En fait, il est converti à peu près en cela en interne.)

Comme exemple d'utilisation d'une clause ":foreach" où une règle de modèle n'est pas
suffisant, supposons que vous ayez .c fichiers qui sont construits à l'aide d'une sorte de préprocesseur
qui prend en entrée des fichiers avec un .k extension. Vous voulez compiler ces .c fichiers avec un
ensemble d'options de compilation différent de l'habituel .c fichiers qui sont une source ordinaire
des dossiers. Tu pourrais faire quelque chose comme ça :

# Règle pour les fichiers .c ordinaires :
%.o : %.c
$(CC) $(CFLAGS) -c $(entrée) -o $(sortie)

# Règle pour créer des fichiers .c à partir de fichiers .k :
%.c : %.k
$(préprocesseur) $(entrée) > $(sortie)

# Règles de construction spéciales pour les fichiers .c créés à partir de fichiers .k :
$(foreach:%.k=%.o) : $(foreach:%.c=%.k) : foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(entrée) -o $(sortie)

(Cela utilise la syntaxe de référence de substitution légèrement plus concise plutôt que d'appeler
"patsubst" explicitement.)

Notez que si tout ce que vous voulez faire est de changer la valeur d'une variable ("CFLAGS" dans ce
cas), il est parfois plus pratique d'utiliser des variables spécifiques à la cible.

Legacy suffixe
Pour une compatibilité descendante, makepp prend en charge les règles de suffixe à l'ancienne.

.suffix1.suffix2 :
actes

équivaut à

%.suffix2 : %suffix1
actes

mais beaucoup plus difficile à retenir. (Quel suffixe vient en premier ?) Généralement, une règle apparaît
dans un makefile hérité comme celui-ci :

.co:
$(CC) $(CFLAGS) -c $*.c -o $*.o

ce qui équivaut exactement à

%.o : %.c
$(CC) $(CFLAGS) -c $(entrée) -o $(sortie)

Contradictoire
Lorsqu'il existe plusieurs façons de créer un fichier, makepp utilise une procédure simple pour
déterminer quelle règle utiliser.

· C'est une erreur d'avoir des règles explicites contradictoires pour la construction d'un fichier.

· Les règles de modèle et les règles foreach avec des caractères génériques ne remplacent jamais les règles explicites. Ainsi
des règles explicites peuvent être utilisées pour spécifier des exceptions pour les règles de modèle. (Notez que simplement
l'utilisation d'une clause ":foreach" ne fait pas de quelque chose une règle de modèle. Il doit avoir un
caractère générique (comme "*" ou "?") dans le nom de fichier dans la clause ":foreach". Si c'est
juste une liste explicite de fichiers, elle est traitée comme une règle explicite pour chacun de ces
des dossiers.)

· Lorsque des règles de modèle en conflit proviennent de différents makefiles, les règles de "plus proche"
les makefiles remplacent les règles des makefiles "plus éloignés". "Plus proche" signifie que le makefile
est situé plus près de la cible dans la hiérarchie des répertoires (c'est-à-dire le nom de fichier du
target par rapport au répertoire à partir duquel le makefile est exécuté est plus court). Si ce
ne distingue pas les makefiles, alors la règle du makefile qui est chargé
dernier est utilisé.

Cela signifie que vous pouvez spécifier une règle de modèle qui s'applique à tous les fichiers de votre
l'intégralité de l'arborescence des répertoires dans le fichier makefile de niveau supérieur, mais vous pouvez ensuite le remplacer dans
un makefile de niveau inférieur. Par exemple, votre makefile de niveau supérieur peut contenir :

%.o : %.c : pour chaque **/*.c
$(CC) $(CFLAGS) -c $(entrée) -o $(sortie)

et vous pourriez avoir un makefile dans l'un des sous-répertoires qui dit :

%.o : %.c
$(CC) $(SPECIAL_CFLAGS) -c $(entrée) -o $(sortie)

· Les règles de modèle qui ont une chaîne d'inférence plus courte sont préférées aux autres modèles
règles. Par exemple, si vous aviez les règles suivantes (basées sur un exemple du
Noyau Linux) :

%.s : %c
$(CC) -s $(entrée) -o $(sortie)

%.o : %s
$(AS) $(entrée) -o $(sortie)

%.o : %c
$(CC) -c $(entrée) -o $(sortie)

Si nous devons construire "xyz.o", nous pouvons soit construire le fichier intermédiaire ".s" puis
exécutez cela via l'assembleur en utilisant les deux premières règles, ou nous pourrions aller directement à un
".o" en utilisant la dernière règle. La dernière règle est préférée car il y a moins
étapes de la chaîne d'inférence (une au lieu de deux).

· Les règles de modèle plus tard dans un makefile remplacent les règles de modèle qui sont antérieures. (C'est
à l'envers de GNU make.) Cela signifie que vous devez mettre vos règles plus générales
plus tôt, et vos règles plus spécifiques plus tard. Par exemple,

%.o: %.c # Règle générale de compilation.
action

special_%.o: special_%.c # Règle spéciale pour les fichiers avec un
action différente # préfixe "special_".

Règle Options
Parfois, il est nécessaire de fournir des options supplémentaires pour modifier la façon dont makepp exécute le
régner. Ces options sont spécifiées comme ":optionname value", soit sur la ligne contenant
les dépendances, ou sur la ligne suivante.

Fournir les options sur des lignes séparées peut vous permettre d'utiliser le même
makefile avec makepp et un make traditionnel. Par exemple,

cible : dépendances
: signature target_newer
actes

fonctionnera bien avec une marque Unix traditionnelle, car elle interprète la ligne ": signature"
comme une commande shell, et une commande commençant par deux points ne fait rien.

:build_cache /chemin/vers/construire/cache
cible : dépendances
: build_cache /put/cache/files/over/there
actes

Spécifie le chemin d'accès à un cache de génération à utiliser pour les fichiers produits par cette règle. Cette
remplace l'effet de l'instruction "build_cache" ou de la commande "--build-cache"
option de ligne, le cas échéant, pour cette règle. Voir makepp_build_cache pour plus de détails sur la construction
cache.

Si vous spécifiez "aucun" au lieu d'un chemin, vous désactivez le cache de construction pour ce
règle particulière. Cela peut être utile pour éviter de gaspiller de l'espace disque sur des fichiers que vous
savoir ne sont pas utiles à mettre en cache, non plus parce que vous êtes très sûr qu'ils ne le seront jamais
réutilisés ou parce qu'ils sont construits si vite que cela ne vaut pas la peine de les mettre en cache.

:build_check build_check_method
cible : dépendances
: build_check target_newer
actes

Cela indique à makepp quel algorithme utiliser pour décider si les cibles doivent être reconstruites.
Voir makepp_build_check pour plus de détails. Cela annule l'effet de la
l'instruction "build_check" ou l'option de ligne de commande "--build-check-method", le cas échéant, pour
cette règle.

:env VARIABLE
Ajoutez une dépendance sur les valeurs des variables d'environnement nommées. Si l'un d'eux
diffèrent de la version précédente, alors les cibles sont considérées comme obsolètes, si le
la méthode build_check le dicte. (Toutes les méthodes de vérification de build intégrées, à l'exception de
target_newer respecte cela.)

VARIABLE peut être de la forme "nom de fichier dans PATH_VARIABLE" (entre guillemets), auquel cas le
les cibles sont considérées comme obsolètes si le premier répertoire du
la valeur de PATH_VARIABLE dans laquelle le nom de fichier existe est différente de la dernière version.
Cela peut être utilisé pour éviter de reconstruire les cibles lorsque PATH_VARIABLE change dans un
manière non pertinente.

:envoi commander
Entourez chaque action du shell (mais pas les actions Perl ni les commandes Perl) dans un "sh -c '...'"
et préfixez-le avec la commande, mais supposez que la cible ne dépend pas de la commande.
Ceci est utile si vous souhaitez envoyer des actions à un système de file d'attente de travaux, mais le résultat est
supposé être indépendant des paramètres de mise en file d'attente, ainsi que de savoir si la mise en file d'attente
système est utilisé du tout.

:comprendre fichier_ou_motif
La règle varie selon le compilateur :

%.o : %.c
: inclure %.d : signature C
gcc -MD -c ...

%.o : %.c
: include %.u : signature C # IBM utilise un suffixe différent
xlc -M -c ...

sub dependify { # Transforme le bavardage de Microsoft en un format utile
s/\$/\$\$/g ;
s/(Remarque : fichier inclus : *)?(.+?)\r?\n/$1 ? "'$2' " : "'".f_output()."': "/e;
}
%.o : %.c
: inclure %.d : signature C
cl -showIncludes -c ... >$(stem).d
&sed &dependify -o +<$(stem).d

Certains compilateurs (icc d'Intel comme gcc ci-dessus, ou xlc d'IBM) peuvent produire une dépendance
fichiers à la volée. C'est-à-dire que pendant qu'ils compilent, ils écrivent un makefile que makepp peut
comprendre. L'avantage par rapport au scanner de makepp est qu'il est garanti à 100%
correct, où nous ne pouvons que nous en approcher.

Cette option exploite cela d'une manière spéciale : Si le fichier n'est pas présent, c'est-à-dire
généralement sur la 1ère version, l'analyse normale se produit. Mais si le fichier est présent, non
l'analyse se produit (c'est pourquoi nous spécifions une signature intelligente ci-dessus - pas l'analyse ne tombe
retour à la valeur par défaut stupide de l'horodatage et de la taille). Au lieu de cela, il inclut le fichier, avant
l'exécution de la règle. Après avoir exécuté avec succès la règle, il oublie tout ce qu'il
lu la première fois, étant donné que le fichier est peut-être obsolète. Au lieu de cela, il lit
le fichier à nouveau, s'il a changé, pour avoir des informations de construction à jour.

AVERTISSEMENT : Ceci est intrinsèquement peu fiable. Le fichier de dépendance est produit par le très
règle dont il est une dépendance. D'un autre côté, le compilateur connaît tout
ce sont des sous-inclus internes, que makepp ignore généralement. C'est une fiabilité
avantage uniquement pour le cas où un patch de compilateur ne corrige que les sous-inclus. Les
Le prix est que makepp finit par regarder beaucoup plus de fichiers, ce qui prend du temps.

Il y a un hic lorsque vous supprimez une instruction "#include" ainsi que le fichier correspondant :
Il sera toujours mentionné dans le fichier de dépendances de la dernière fois, lorsqu'il a été
nécessaire. Dans un tel cas, vous devez éditer le fichier de dépendance pour supprimer la dépendance
qui n'est plus réalisable.

Cette fonctionnalité ne peut pas être utilisée avec un cache de construction car récupérer un fichier à partir de là
nécessite de tout savoir sur le fichier. Mais un fichier de dépendance dépend de ceux
fichiers que makepp apprend en le lisant. Une telle dépendance circulaire n'est normalement pas
possible dans un système de construction fiable. Ceci est une exception car après la reconstruction
et en relisant un fichier de dépendance tout est à nouveau correct.

Si vous construisez dans vos référentiels, makepp récupérera le fichier de dépendance à partir du
1er référentiel qui en contient un. Ceci est différent des autres fichiers, où il faut le 1er
avec la signature attendue. C'est mieux que pour les caches de build, où faute de
signature, il ne peut même pas trouver le fichier.

:dernière chance
Activer une règle ouverte, telle que

%.foo foo%.bar : :dernière_chance
&écho $@ -o $@
&cp $(sorties)

Parce qu'une règle comme celle-ci pourrait générer un nombre essentiellement infini de cibles,
une cible de cette règle ne correspondra pas à une fonction $(wildcard) ou à une règle de modèle à moins que
quelque chose d'autre a déjà instancié la règle en référençant spécifiquement la cible.
De plus, si "--rm-stale" est spécifié, alors une cible restante d'un précédent
makepp run apparaîtra obsolète si la seule façon de le construire est via une règle last_chance
qui n'a pas encore été instanciée pour la cible, ce qui est un comportement souhaitable car
la construction échouera de manière plus cohérente lorsqu'elle s'appuie à tort sur un caractère générique pour
faire correspondre les cibles d'une course précédente.

L'option ":last_chance" est destinée à attirer l'attention sur le comportement particulier du
règle concernant les caractères génériques correspondants.

:analyseur analyseur
Cela indique à makepp comment analyser la commande pour détecter (inclure) les fichiers. D'habitude,
makepp devine comment faire cela en fonction des mots de la commande elle-même (voir
makepp_scanning pour plus de détails). Cependant, si makepp se trompe, vous voudrez peut-être
indiquer explicitement l'analyseur, comme ceci :

%.o : %abc
: analyseur c_compilation
agir ici

Cela oblige makepp à effectuer la même analyse et la même analyse que pour C/C++
build, même s'il ne reconnaît pas l'action comme une compilation C.

L'analyseur par défaut dépend de la commande. Si vous ne spécifiez pas d'option ":parser",
puis le premier mot de chaque commande est examiné. Par exemple pour une compilation ou un lien
commande, makepp utilisera l'analyseur "c_compilation" ; ou si la commande ressemble au
Variante GNU, "gcc_compilation". Si aucun analyseur n'est trouvé, il utilise l'analyseur "aucun". Pour
plus de détails à ce sujet, ou si vous voulez écrire votre propre analyseur syntaxique ou modifier celui de makepp
parseurs par défaut, voir makepp_scanning.

Notez que cela s'applique à chaque commande de la règle, ce qui peut ne pas être ce que vous voulez :

%.o : %.c : analyseur c-compilation
@echo 'Building $(output)'
@drôle_cc ...

Cela interprétera également "echo" comme un compilateur et en déduira son argument 'Building
mymodule.o' en tant que dépendance implicite. Cela conduira à la plainte qu'il
ne sait pas comment construire un tel fichier. Dans ce cas, vous feriez mieux de
"register_parser". Vous y trouverez une explication comment analyseur peut être donné soit comme un
nom de classe ou comme nom de fonction.

:Signature méthode_signature
cible : dépendances
: signé md5
actes

Cela indique à makepp quel algorithme utiliser pour déterminer si les dépendances ont changé.
Voir makepp_signatures pour plus de détails. Les méthodes de signature qui sont incluses avec le
Les distributions makepp sont "plain", "md5", "C" ou "c_compilation_md5", et
"objet_partagé". Cela remplace toute méthode de signature spécifiée avec le "-m" ou
les options de ligne de commande "--signature-method", ou avec l'instruction "signature".

# caractères
Makepp peut prendre en charge les noms de fichiers contenant des caractères spéciaux tels que deux points ou un espace.
Supposons, par exemple, que vous souhaitiez créer un fichier appelé "a:thing" à partir du fichier "b:thing".
Vous ne pouvez pas écrire la règle de cette façon :

a:thing : b:thing # Ceci est une erreur de syntaxe
&cat $(entrée) -o $(sortie)

parce que makepp ne saura pas quels deux points séparent les cibles des dépendances et lesquelles sont
partie des noms de fichiers. Au lieu de cela, placez simplement le nom entre guillemets, comme ceci :

"a:chose" : "b:chose"
&cat $(entrée) -o $(sortie)

Désormais, la règle est sans ambiguïté.

La syntaxe des guillemets de Makepp est assez similaire à celle du shell. Vous pouvez, par exemple, utiliser un seul
guillemets au lieu de guillemets doubles, ou vous pouvez échapper des caractères spéciaux avec une barre oblique inverse :

a\:chose : 'b:chose'
&cat $(entrée) -o $(sortie)

Supposons, par exemple, que votre nom de fichier soit "'" !;\$". Maintenant, pourquoi voudriez-vous un tel nom de fichier
Je ne sais pas, mais voici plusieurs façons de le spécifier à makepp (et au shell):

\''" !;\$$'
"'\" !;\\$$"

Faites attention à quand makepp supprime les guillemets et quand le shell le fait. Makepp regarde
devis uniquement dans les cas suivants :

· dans la famille de tests "ifeq"

· avant et après la règle deux points

· dans une commande intégrée makepp

· dans une fonction relative aux fichiers

Contrairement au shell, makepp ne développe pas les guillemets tout en les affectant à une variable. Ainsi
les règles suivantes sont identiques :

FILE = 'nom avec espaces'
x := $(print $(FILE)) # juste pour vérifier que les guillemets sont toujours là
$(FILE): # guillemets autour d'un seul fichier supprimé par makepp
&echo hello -o$(FILE) # guillemets autour d'un seul fichier supprimé par makepp
echo there >>$(FILE) # guillemets autour d'un seul fichier supprimé par Shell
'nom avec espaces' :
&echo hello -o'nom avec espaces'
echo here >>'$(output)' # les guillemets ont été supprimés ci-dessus, ajoutez-les à nouveau

Notez que (contrairement au Shell) les variables commençant par "$" sont développées même à l'intérieur
devis. Les signes dollar ne peuvent pas être protégés par des guillemets ou des barres obliques inverses. Pour obtenir un littéral
signe dollar, utilisez un signe dollar double, par exemple,

$(faux tous) :
@&echo Ceci est un signe dollar : $$
@for val dans abcd ; faire écho $$val ; terminé

En règle générale, vous devriez être capable de traiter à peu près n'importe quel caractère spécial en le citant
en quelque sorte. Cela inclut les espaces, les caractères de contrôle, etc. Cependant, sachez qu'à
présent, la suppression des commentaires de makepp est quelque peu simpliste et tous les caractères "#"
précédés d'espaces seront interprétés comme des commentaires, quelle que soit la manière dont ils sont cités.

Lorsqu'un nom de cible ou de dépendance est mis dans une variable automatique comme "$(output)", alors
les guillemets et les barres obliques inverses sont supprimés. Cela signifie que si vous souhaitez référencer le
nom de fichier dans les actions, vous devrez probablement le citer à nouveau, comme ceci :

"un nom de fichier avec des espaces":
echo "Contenus spéciaux" > "$@"

Si vous ne mettez pas les guillemets autour de $@, alors le shell verra la commande

echo "Contenus spéciaux" > un nom de fichier avec des espaces

qui écrit la chaîne "Nom du fichier de contenu spécial avec des espaces" dans le fichier appelé a.
Ce n'est probablement pas ce que vous voulez.

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