makepp_command - En ligne dans le Cloud

PROGRAMME:

Nom

makepp -- syntaxe de ligne de commande pour makepp

DESCRIPTION

?: - ?, A: -UNE,
--args-fichier,
--fichier-arguments,
--assume-nouveau,
--suppose-vieux, B: -b,
--build-cache,
--build-check,
--build-check-method, C: -Ç,
-c, D: --defer-include,
--annuaire,
--faire-construire,
--ne pas construire,
--ne pas lire,
--faire-lire,
--à sec,
--dump-makefile,
--dump-makeppfile, E: -e,
--environnement-overrides,
--env-overrides, F: -F,
-F,
--déposer,
--règles finales uniquement,
--force-copie-de-bc,
--force-rescan, G: --crédule, H: -h,
--aider,
--hybride,
--hybride-récursivité,
--hybrid-recursive-make, I: -JE,
--implicit-load-makeppfile-only,
--comprendre,
--include-dir,
--dans-bac à sable,
--intérieur-bac à sable, J: -j,
--travaux,
--juste-imprimer, K: -k,
--continue, L: --les-règles-de-la-dernière-chance,
--load-makefile,
--load-makeppfile,
--Journal,
--fichier journal,
--boucle, M: -m,
--makefile,
$FAIRE DES FLAGS,
$MAKEPP_CASE_SENSITIVE_FILENAMES,
--makeppfile,
$MAKEPPFLAGS,
--md5-bc,
--md5-check-bc, N: -n,
--nouveau fichier,
--pas de règles intégrées,
--no-cache-scaninfos,
--pas de charge implicite,
--pas de journal,
--dépendances-exécutables sans chemin,
--no-path-exe-dep,
--no-populate-bc,
--pas de répertoire d'impression,
--no-remake-makefiles,
--pas d'avertissement, O: -o,
--ancien-fichier,
--hors bac à sable,
--override-signature,
--override-signature-method, P: --populate-bc-only,
--profil, Q: --calmer, R: -R,
-r,
--reconnaissance,
--remove-stale,
--remove-stale-files,
--dépôt,
--rm-vicié,
--rép-racine,
--répertoire-racine, S: -Oui,
--bac à sable,
--sandbox-warn,
--avertissement-bac à sable,
--Signature,
--signature-méthode,
--silencieux,
--arrêter,
--stop-après-chargement,
--arrêter-avant-de-construire,
--arrêt en course,
--stop-course,
--symlink-in-rep-as-file,
--lien symbolique dans le référentiel en tant que fichier, T: --traditionnel,
--traditionnel-récursivité,
--fabrication-récursive-traditionnelle, V: -V,
-dans,
--verbeux,
--version,
--bac à sable virtuel, W: -W,
--Et qu'est-ce qui se passerait si

makepp [ option ... ] [ VAR=valeur ] [ l'objectif ...]

député [ option ... ] [ VAR=valeur ] [ l'objectif ...]

Makepp prend en charge la plupart des options de ligne de commande et de la syntaxe prises en charge par les autres fabricants. Les
les tirets entre les mots sont toujours facultatifs et peuvent également être remplacés par un trait de soulignement.
Vous spécifiez une liste de cibles à construire sur la ligne de commande. Si vous ne spécifiez aucun
cibles, la première cible explicite dans le makefile est construite.

Vous pouvez affecter des variables sur la ligne de commande qui remplaceront toute affectation ou
variable d'environnement dans chaque Makefile chargé, par exemple,

makepp CFLAGS=-O2

Les options valides sont la plupart des options de fabrication standard, plus quelques nouvelles :

-A nom de fichier
--args-file=nom de fichier
--arguments-file=nom de fichier
Lisez le fichier et analysez-le comme éventuellement entre guillemets et/ou saut de ligne séparé
options.

-b annuaire
--build-cache=annuaire
Spécifie le chemin d'accès à un cache de génération. Voir makepp_build_cache pour plus de détails. La construction
le cache doit déjà exister ; voir "Comment gérer un cache de build" dans makepp_build_cache pour
comment le faire en premier lieu. Les caches de construction définis sur la ligne de commande peuvent être
remplacé par une instruction build_cache dans un makefile ou un modificateur de règle :build_cache .
Si vous travaillez avec plusieurs versions différentes, il peut être utile de définir l'environnement
variable "MAKEPPFLAGS" pour contenir "--buil""d-cache=/path/to/build/cache" afin que tous
de vos builds tireront parti du cache de build par défaut.

--build-check=méthode
--build-check-method=méthode
Le nom d'une méthode de vérification de génération à utiliser pour décider si les fichiers doivent être reconstruits.
Les valeurs possibles sont "target_newer", "exact_match", voir makepp_build_check pour
informations sur les méthodes de vérification de la construction.

-C annuaire
--répertoire=annuaire
Cd dans le répertoire donné avant de charger le makefile et d'essayer de construire les cibles.
Ceci est similaire à la spécification d'un répertoire avec "-F", sauf que le "-C" suivant
Les options "-f", "-F", "-I" et "-R" sont interprétées par rapport au nouveau répertoire,
plutôt que l'ancien.

-c
--rép-racine
--répertoire-racine
Cd jusqu'au répertoire contenant un fichier RootMakepp.

--defer-include
Solution de contournement pour l'instruction d'inclusion avant la règle qui génère le fichier d'inclusion. Cette
se produit en prétendant que les instructions include arrivent en dernier dans le makefile. De cette façon le
L'instruction include est exécutable, mais les remplacements ou modifications de variables peuvent toujours
échouer, auquel cas vous devez définir les problèmes sur la ligne de commande (tandis que
gmake ignore tout paramètre de variable du fichier d'inclusion qui pourrait influencer la façon dont cela
le fichier lui-même est construit).

--dont-build=nom de fichier
--do-build=nom de fichier
Ne construisez pas le fichier spécifié, ou, s'il s'agit d'un répertoire, tout ce qui se trouve en dessous, même
bien que makepp pense qu'il devrait -- ou qu'il construit, en remplaçant la spécification opposée
à partir d'un répertoire supérieur. Ceci est utile si vous avez construit un fichier spécifique à la main en utilisant
différentes options de compilation. Sans cette option, si vous compilez un module à la main
puis exécutez makepp pour compiler le reste du programme, makepp recompilera également le
module que vous avez compilé à la main, car makepp ne peut pas garantir que la construction est correcte
si l'un des fichiers n'a pas été construit sous son contrôle. Avec cette option, vous dites
makepp que vous savez vraiment ce que vous faites dans le cas de ce fichier particulier et
tu promets qu'il n'y a pas de mal à ne pas le reconstruire.

Par exemple,

% cc -g -DSPECIAL_DEBUG -c xc -o xo # Compilation spéciale à la main
% makepp
cc -g -O2 -c xc -o xo # Makepp vient d'écraser votre compilation ici !
cc xo yo -o mon_programme # Relie.
% cc -g -DSPECIAL_DEBUG -c xc -o xo # Recommencez.
% makepp --dont-build xo # Dites à makepp de ne pas reconstruire xo même s'il le souhaite.
cc xo yo -o mon_programme # Maintenant, il se reconnecte sans recompiler.

Si vous voulez des options de compilation spéciales pour un seul module, il est souvent plus facile de les éditer
le makefile que de compiler à la main comme dans cet exemple ; voir "Cible-spécifique
assignations" dans makepp_variables pour un moyen simple de le faire.

Si vous mettez un Fichier RootMakepp(.mk) à la racine de votre système de construction, ce répertoire et
tout en dessous est par défaut "--do-build", tandis que la racine globale de votre fichier
le système par défaut est "--dont-build". De cette façon, tout ce qui se trouve à l'intérieur de votre système de construction est
construit (si nécessaire) mais rien à l'extérieur n'est tenté. Si, dans ce scénario, vous voulez
les pièces externes doivent toujours être construites selon les besoins, vous devez explicitement les récupérer avec
instructions "load_makefile" dans l'un des makefiles de votre arborescence.

Vous pouvez en avoir un Fichier RootMakepp(.mk) chacun, dans des arbres de construction séparés, et ils seront
chargé si un arbre a des dépendances dans un autre. Mais vous n'êtes pas autorisé à avoir
Fichier RootMakepp(.mk) dans les répertoires imbriqués, en évitant les effets amusants qui ont tendance à se produire
lorsque vous appelez accidentellement à nouveau "makepp --repository" dans un sous-répertoire. Ces
les effets incluent des règles dupliquées via des sources dupliquées ou un cache de construction éternel
réimporte car les fichiers mis en cache ont les bonnes signatures mais le mauvais parent
chemins.

Remplacez "--dont-build" pour le fichier ou le répertoire spécifié. Si tu as un
Fichier RootMakepp(.mk) à la racine de votre système de compilation, mais vous voulez que makepp compile
quelque chose en dehors de votre système de construction juste cette fois, vous devez le marquer explicitement comme
"--faire-construire". Si vous spécifiez "--do-build" pour un fichier ou un répertoire sous un
Fichier RootMakepp(.mk), sans "--dont-build" pour un répertoire supérieur, puis la racine (et
tout le reste en dessous) de votre système de construction par défaut sur "--dont-build".

Pour résoudre les conflits entre "--dont-build" et "--do-build", celui qui a le plus
chemin spécifique prévaut quel que soit l'ordre. Si le même chemin est spécifié
avec à la fois "--dont-build" et "--do-build", alors le plus à droite gagne.

Les options "--dont-build" et "--do-build" peuvent être dangereuses si vous donnez le mauvais
conseils à makepp, puisque vous demandez à makepp de ne pas faire les vérifications dont il a besoin, pour garantir un
construction correcte. Mais comme ils permettent de réduire fortement le nombre de contrôles, ils peuvent
accélérez considérablement vos builds, comme expliqué dans les méthodes d'accélération potentiellement dangereuses.

--ne pas lire=nom de fichier
--do-read=nom de fichier
Ne pas lire le fichier spécifié, ou, s'il s'agit d'un répertoire, tout ce qui se trouve en dessous -- ou
do read, en remplaçant la spécification opposée à partir d'un répertoire supérieur. Générer un
erreur plutôt que de lire les fichiers marqués pour "--dont-read". Voir --sandbox. Le système de fichiers
root est toujours par défaut lisible.

--dump-makefile=nom de fichier
--dump-makeppfile=nom de fichier
Videz le contenu brut du ou des makefile(s) pour le répertoire actuel (tel que déterminé par
la position de cette option par rapport à toute option "-C") pour nom de fichier. Inclure les fichiers
sont interpolés, les commentaires sont supprimés et les "ifdef" sont résolus. "# ligne
Des marqueurs « fichier » sont insérés si nécessaire. La valeur finale de toute non-référence
les scalaires dans le package du makefile sont imprimés après le makefile.

Ceci est utile pour le débogage, mais (actuellement) vous ne pourrez pas nécessairement utiliser le
dump en tant que makefile équivalent, par exemple parce qu'il contient à la fois l'include
l'instruction et le fichier interpolé.

-e
--env-overrides
--environnement-overrides
Les variables de l'environnement remplacent les définitions dans le makefile. Par
par défaut, les affectations dans le makefile remplacent les valeurs des variables qui sont importées
de l'environnement.

-F Makeppfile
--makeppfile=Makeppfile
Charge le Makefile spécifié ou, si vous spécifiez un répertoire, le Makefile la bride,
au lieu de celui du répertoire courant -- toute cible spécifiée à droite de
cette option est interprétée par rapport au répertoire contenant le Makefile. Pour le
les détails de l'affaire du répertoire et Fichier RootMakepp voir l'explication au prochain
option.

Cette option peut être utile si vous exécutez makepp à partir de répertoires imprévisibles. Pour
exemple, si vous compilez depuis emacs et que vous avez des sources dispersées partout dans votre
arborescence de répertoires, le répertoire de travail courant pour la commande de compilation sera le
répertoire dans lequel se trouvait le dernier fichier source que vous avez modifié, qui peut ou non être le premier
level pour votre compilation. Cependant, vous pouvez spécifier votre compilation
commande comme

makepp -F /votre/source/dir/top

et cela fonctionnera quel que soit votre répertoire actuel.

Parce que cette option n'affecte pas le répertoire par rapport auquel le "-C" suivant,
Les options "-f", "-F", "-I" et "-R" sont spécifiées, vous pouvez créer des cibles relatives au
répertoire courant comme ceci :

makepp -F /foo/bar -C . ma cible

-f Makefile
--fichier=Makefile
--makefile=Makefile
Charge le Makefile spécifié ou, si vous spécifiez un répertoire, le Makefile la bride,
au lieu de celui du répertoire courant. Si vous ne spécifiez pas l'option "-f" ou
l'option "-F", makepp recherche d'abord un fichier dans le répertoire courant (ou le
répertoire spécifié par l'option "-C" la plus à droite, le cas échéant) appelé, puis
RootMakeppfile.mk, Makeppfile, puis Makeppfile.mk, puis makefile, puis Makefile.
Plusieurs options "-F" et "-f" peuvent être spécifiées.

Les deux premiers (Fichier RootMakepp) sont spéciaux (qu'ils soient donnés explicitement ou trouvés
implicitement). Il doit y avoir au plus un de ces deux dans un arbre de construction donné sur lequel
makepp doit fonctionner. Mais il peut y en avoir plusieurs si vous construisez plusieurs arbres disjoints dans
une seule fois. Ces deux-là sont recherchés non seulement dans le répertoire susmentionné, mais aussi
vers le haut à partir de là. S'il en trouve un, il est chargé avant les autres.

--final-rules-uniquement
Ignorez les dépendances et les cibles implicites de la règle, sauf si la cible est fausse.

--force-copie-de-bc
Lorsque vous utilisez des caches de construction, copiez toujours les fichiers dans et hors du cache, même si la source
et la cible sont sur le même système de fichiers. Ceci est principalement utile pour tester (émuler)
le cas où ils ne le sont pas.

--force-rescan
N'utilisez pas les résultats de l'analyseur mis en cache des exécutions précédentes.

--crédule
Croyez que les règles créent ce qu'elles déclarent, plutôt que de vérifier. C'est
plus rapide, mais n'attrape pas les bogues dans les règles.

-?
-h
--Aidez-moi
Imprimez un bref résumé des options.

--hybride
--hybride-récursion
--hybrid-recursive-make
Cette option est présente pour permettre à makepp de fonctionner avec d'anciens makefiles qui utilisent récursif
faire abondamment, surtout multiplier dans le même dir. Par défaut, make récursif
est implémenté par un sous-processus qui communique avec le processus parent ; la construction est
effectivement fait par le processus parent. Cela permet certaines des fonctionnalités intéressantes de makepp comme
référentiels pour travailler avec des appels make récursifs. Cependant, cette technique va
ne fonctionnera pas si vous chargez plus d'un makefile à partir du même répertoire. Dans ce cas
cette option dit de revenir au démarrage d'une autre instance indépendante de makepp. Si
cela échoue, essayez "--traditional-recursive-make".

Si vous utilisez cette option, vous obtiendrez des fichiers journaux dans chaque répertoire de secours
s'est produit. Pour les supprimer uniquement, utilisez "makeppclean --logs --recurse" ou "mppc
-g / D".

-I annuaire
--include=annuaire
--include-dir=annuaire
Recherchez dans le répertoire donné les makefiles inclus.

--implicit-load-makeppfile-only
Si le chargement implicite des makefiles est activé, alors ne charge automatiquement qu'un fichier
appelé Fichier RootMakepp, RootMakeppfile.mk, Makeppfileou Makeppfile.mket ne sauraient
makefile or Makefile. Ceci est utile si makepp a des dépendances générées par
une autre variante de make, et makepp ne peut pas lire les makefiles de cette variante en général.
(Vous voulez éviter cette situation si possible, mais elle a tendance à survenir pendant que vous êtes en
le processus de portage d'un système de build hérité vers makepp.) Cela n'a aucun effet si
le chargement implicite est désactivé.

-j n
--emplois=n
interprète l'argument n comme le nombre de commandes shell qui peuvent être exécutées dans
parallèle. Par défaut, makepp n'exécute pas de commandes en parallèle.

Contrairement à d'autres versions de make, lorsque les tâches sont exécutées en parallèle, makepp dirige
leur sortie dans un fichier et n'affiche la sortie que lorsque les commandes sont terminées.
Cela empêche la sortie de plusieurs commandes différentes d'être mélangées sur le
l'affichage, mais cela signifie que vous devrez peut-être attendre un peu plus longtemps pour voir le
sortie, et les messages stderr apparaîtront généralement avant les éléments stdout, à la différence de
sortie terminale.

Native Windows Perls (c'est-à-dire Strawberry et ActiveState), car ils ne prennent pas en charge
le paradigme Unix fork/exec, n'autorisez pas cette option (Cygwin fonctionne bien !). Comme un
remplacement partiel, vous pouvez utiliser l'option --sandbox là, bien que ce soit beaucoup moins
confortable.

-k
--continue
Créez autant de fichiers que possible en toute sécurité, même si certaines commandes contiennent des erreurs. Par
par défaut, makepp s'arrête lorsqu'il rencontre la première erreur, même s'il y a d'autres
fichiers qui doivent être construits et qui ne dépendent pas du fichier erroné.

--règles-de-la-dernière-chance
Activez la gestion spéciale limitée pour les règles de modèle avec '%' uniquement du côté cible.
Ceci est nécessaire car normalement, contrairement aux marques traditionnelles, makepp instancie tous
règles avec tous les fichiers disponibles de bas en haut, lui permettant de trouver tous les
dépendances.

--load-makefile=Makefile
--load-makeppfile=Makefile
Charge le makefile spécifié before tout autre makefile, à l'exception de Fichier RootMakeppou
RootMakeppfile.mk au-dessus, mais n'envisagez pas cette option aux fins de
déterminer la cible par défaut. Si aucun autre makefile n'est spécifié, alors un est recherché
en utilisant les règles habituelles. Si le makefile spécifié est le même makefile qui est trouvé
en utilisant les règles habituelles, cette option n'a aucun effet.

--log=nom du fichier journal
--log-file=nom du fichier journal
Remplace le nom du fichier journal par le nom indiqué. Par défaut, le fichier journal est
appelé .makepp/log. Ce fichier est lisible avec makepplog, mppl.

--boucle
--arrêter
--stop-avant-construction
--stop-après-chargement
Makepp s'arrêtera à plusieurs reprises (s'endormira), avant d'analyser et de construire
n'importe quoi, pour que vous le réveilliez quand vous êtes prêt. Il vous indiquera quelques commandes pour
choisissez parmi pour le réveiller à nouveau. Si vous le faites dans un Shell, vous obtenez l'invite et
peut alors le précéder ou l'arrière-plan. Si vous le faites dans un IDE, il va simplement dormir, et
vous pouvez le réveiller à partir d'un autre Shell. Selon l'endroit où vous le démarrez, la fermeture
window peut ou non terminer makepp, alors vérifiez comment faire face à cela dans votre
environnement.

L'intention est que vous puissiez démarrer makepp de cette façon avant d'avoir fini d'éditer
certains fichiers. Selon la structure et la taille de votre projet, cela peut permettre à makepp de
obtenez une longueur d'avance de plusieurs secondes de travail au moment où vous avez terminé. Puis chaque
temps, vous pouvez éditer plus et le réveiller à nouveau, à moins que vous ne changiez quelque chose dans votre
Makefile, qui passera inaperçu jusqu'à ce que vous commenciez une nouvelle instance de makepp. Le même
s'applique aux référentiels, qui ne doivent jamais changer pendant l'exécution de makepp.

Si vous utilisez "prebuild" ou "$(make)", au premier tour, il s'arrêtera quand il arrivera à
ce point.

-m méthode
--signature=méthode
--signature-method=méthode
Spécifie la méthode de signature par défaut à utiliser pour les règles qui n'ont pas le
Modificateur ":signature" dans les makefiles qui n'ont pas d'instruction "signature". Fait
ne remplace pas le choix fait par les analyseurs de commandes, par exemple les compilateurs C/C++. Possible
les valeurs sont "md5", "C" ou "c_compilation_md5", "xml" et "xml-space". Pour plus
détails, voir makepp_signatures.

--md5-bc
--md5-check-bc
Lors de l'importation à partir d'un cache de build, rejetez les cibles mises en cache à moins que MD5_SUM ne soit présent
et correspond à la cible importée. Lors du remplissage d'un cache de build, calculez et stockez
le MD5_SUM dans les informations de construction s'il n'y est pas déjà. Ceci est plus lent et conduit à
plus de reconstructions, mais cela garantit que les cibles importées et les fichiers d'informations de construction correspondent
exactement.

-n
- à sec
--juste-imprimer
--reconnaissance
Imprimer les commandes sans les exécuter réellement - de manière peu fiable là où les commandes dépendent
sur les résultats précédents. Cela vous permet de voir ce que makepp va faire, sans réellement
modifier n'importe quel fichier.

Plus précisément, makepp exécute toutes les commandes make récursives comme d'habitude (mais j'espère
vous n'utilisez pas de make récursif nulle part !). Les autres commandes sont simplement imprimées sans
en cours d'exécution. Même les commandes préfixées par "@" ou "noecho" sont imprimées
après la suppression du "@" ou du "noecho". Cependant, les commandes préfixées par "+" devraient
être exécutés, mais ne le sont pas actuellement.

Mise en garde: Les commandes que makepp exécute avec "-n" ne sont pas nécessairement les mêmes
chose qu'il fera sans "-n". Les signatures de fichiers ne changent pas du tout avec "-n", qui
signifie que makepp ne peut pas effectuer exactement les mêmes tests de build que lorsque le
les signatures changent. Cela fera parfois une différence si vous utilisez
Signatures MD5 (qui est la valeur par défaut pour les commandes de compilation) ou si vous avez un shell
commandes qui peuvent ou non changer la date.

Par exemple, supposons que vous générez un .h via une sorte de préprocesseur. Cette
peut se produire de différentes manières. Pour être concret, supposons que vous automatiquement
générer une liste de prototypes pour les fonctions définies dans chaque module C (voir
<http://cproto.sourceforge.net/> pour le fonctionnement de l'application "cproto" ou
<http://www.lemoda.net/c/cfunctions/> pour les cfunctions similaires).

prototypes.h : *.c
cproto $(CPPFLAGS) $(entrées) > $(sortie)

Puis chacun .c fichier comprendra prototypes.h. Le but est de maintenir la
transmettre automatiquement les déclarations de toutes les fonctions, donc si vous modifiez les
signature ou ajouter une nouvelle fonction, vous n'avez jamais besoin de mettre en avant ou d'externer
déclarations n'importe où. Vous n'avez même pas besoin de déclarer la dépendance de vos fichiers .o
sur celui-ci -- makepp verra l'instruction include et verra automatiquement s'il a besoin
pour (ré)exécuter cproto.

Supposons maintenant que vous en changez un seul .c déposer. Que se passe-t-il lorsque vous exécutez makepp avec "-n"
dans ce cas, c'est qu'il se rend compte que prototypes.h doit être refait. Dans tout
probabilité, refaire prototypes.h n'affectera pas sa signature--le contenu du fichier sera
probablement être identique car aucun argument de fonction n'a été modifié - donc la plupart des
temps, rien qui dépend de prototypes.h doit en fait être recompilé. Mais makepp
ne le sait pas à moins qu'il ne soit réellement autorisé à exécuter les commandes. Donc ça suppose
que tout ce qui dépend de prototypes.h devra également être recompilé. Ainsi dans
cet exemple, en changer un .c fichier fera penser à "makepp -n" que chaque
.c le fichier doit être recompilé, même si probablement la commande makepp habituelle
n'exécutera en fait pas toutes ces commandes.

Cette situation n'est pas si courante et ne peut se produire que si (a) vous utilisez une signature
méthode qui dépend du contenu du fichier plutôt que de la date, comme compilation par défaut
la méthode de signature le fait, ou (b) si vous avez des commandes shell qui ne modifient pas toujours le
Date. Par exemple, avec une implémentation traditionnelle de make qui ne regarde que les dates
au lieu de signatures de fichiers, les gens écrivent parfois des commandes comme celle-ci :

prototypes.h : $(wildcard *.c) # Technique hackée non nécessaire pour makepp
cproto $(CPPFLAGS) $(entrées) > junk.h
if cmp -s junk.h prototypes.h; alors \
rm indésirable.h; \
autre \
mv junk.h prototypes.h; \
fi

Ainsi, si la réexécution de cproto sur tous les fichiers produit exactement le même contenu de fichier, le
la date du fichier n'est pas mise à jour. Cela aura exactement le même problème que ci-dessus
exemple avec "makepp -n": on ne sait pas si la date du prototypes.h change
à moins que la commande ne soit réellement exécutée, donc "makepp -n" ne peut pas être précis à 100%.
(Notez que l'utilisation du traditionnel "make -n" aura également exactement le même problème sur
cet exemple.)

"makepp -n" devrait toujours afficher plus de commandes qu'une invocation régulière de makepp,
pas moins. S'il imprime moins de commandes, cela signifie que makepp ne connaît pas
une certaine dépendance ; un fichier change qu'il ne s'attend pas à changer sur la base
de ce qu'il sait sur les fichiers que chaque règle affecte. Cela signifie que votre makefile
a un bug.

--no-cache-scaninfos
N'enregistrez pas les résultats de l'analyse, forçant sa réexécution la prochaine fois makepp
s'exécute.

--no-implicite-load
Ne charge pas automatiquement les makefiles à partir des répertoires référencés (voir "Chargement implicite"
dans makepp_build_algorithm). Par défaut, makepp charge automatiquement un makefile depuis
tout répertoire qui contient une dépendance d'une cible qu'il doit construire, et à partir de
tout répertoire analysé par un caractère générique. Parfois, cependant, cela provoque une
problème, car les makefiles doivent être chargés avec différentes variables de ligne de commande ou
options, et si elles sont implicitement chargées avant d'être explicitement chargées par un
invocation récursive make ou l'instruction "load_makefile", makepp s'interrompt avec un
Erreur. Vous pouvez également désactiver le chargement du makefile répertoire par répertoire en
en utilisant l'instruction "no_implicit_load" dans l'un de vos makefiles.

--pas de journal
Ne vous embêtez pas à écrire une description détaillée de ce qui a été fait dans le fichier journal. Par
par défaut, makepp écrit une explication de chaque fichier qu'il a essayé de créer, et
pourquoi il l'a construit ou ne l'a pas construit, dans un fichier appelé .makepp/log, lisible avec
makepplog, mppl. Cela peut être extrêmement utile pour déboguer un makefile--makepp
vous dit ce qu'il pensait de toutes les dépendances, et laquelle(s) il pensait
modifié. Cependant, cela prend du temps CPU supplémentaire et vous ne voudrez peut-être pas vous en soucier.

--no-path-exe-dep
--no-path-executable-dependances
Ne pas ajouter de dépendances implicites sur les exécutables récupérés à partir de la recherche de commande
chemin. Si cette option est spécifiée, makepp suppose que tout exécutable dont
le comportement pourrait changer avec une nouvelle version sera spécifié avec un nom contenant un
sabrer.

Ceci est utile pour les programmes tels que grep et diff, qui font toujours fondamentalement la même chose
chose même si leur implémentation change, bien qu'il soit préférable d'utiliser la fonction intégrée
commandes pour grep. Vous pouvez également en avoir besoin pour les référentiels sur les clusters NFS, où le
les mêmes commandes peuvent ne pas avoir le même horodatage partout, ce qui
reconstruit en fonction de la machine sur laquelle quelqu'un travaille.

--no-populate-bc
Ne remplissez pas le cache de build, mais importez-en quand même si possible. C'est
utile lorsque l'environnement peut entraîner la génération différente des cibles, mais
makepp ne connaît pas de telles dépendances. Il est également utile d'éviter de cogner le
cache de construction avec un grand nombre d'écrivains simultanés qui pourraient interférer avec un
un autre.

--no-print-répertoire
Désactivez l'entrée ou la sortie des messages du répertoire.

--no-remake-makefiles
D'habitude, makepp charge chaque makefile, puis regarde s'il y a une règle
qui spécifie comment mettre à jour le makefile. Si c'est le cas et que le makefile doit être
reconstruit, la commande est exécutée et le makefile est relu. Cela provoque souvent
problèmes avec les makefiles produits pour l'utilitaire make Unix standard, car (dans mon
expérience) souvent les règles de make pour mettre à jour les makefiles sont inexactes - elles
omettent fréquemment les cibles qui sont modifiées. Cela peut amener makepp à refaire beaucoup de
fichiers inutilement. Vous pouvez souvent résoudre ce problème en empêchant simplement makepp
de mettre à jour le makefile automatiquement (mais vous devez vous rappeler de le mettre à jour en
main).

--pas d'avertissement
N'imprimez aucun message d'avertissement sur stderr, uniquement dans le fichier journal. La plupart des messages d'avertissement
concernent les constructions que vous pourriez voir dans les makefiles hérités que makepp considère
dangereux, mais certains d'entre eux concernent d'éventuelles erreurs dans votre makefile.

-o nom de fichier
--assume-vieux=nom de fichier
--ancien-fichier=nom de fichier
Prétend que le fichier spécifié n'a pas changé, même s'il l'a été. Toutes les cibles qui
dépendent de ce fichier ne seront pas reconstruits à cause de ce fichier, bien qu'ils puissent être
reconstruit si une autre dépendance a également changé. Le fichier lui-même peut ou non
être reconstruit, selon qu'il est obsolète par rapport à ses dépendances.
(Pour éviter cela, utilisez "--dont-build".)

--override-signature=méthode
--override-signature-method=méthode
Identique à "--signature-method", mais remplace même le choix fait par les analyseurs de commandes.

--hors du bac à sable=nom de fichier
Générez une erreur plutôt que d'écrire des fichiers en dehors du "bac à sable". Comme --dont-build,
les chemins plus spécifiques remplacent les chemins moins spécifiques. La racine du système de fichiers par défaut est
out-of-sandbox s'il existe des options "--sandbox".

Le but du bac à sable est de permettre à plusieurs processus makepp simultanés de
opérer sur des parties disjointes du système de fichiers. Pour que cela fonctionne de manière fiable,
les bacs à sable concurrents ne doivent pas se chevaucher et chaque processus doit marquer le bac à sable de chaque
autre processus makepp simultané pour --dont-read. Voir partitionnement en sandbox.

--populate-bc-only
Ne pas importer depuis le cache de build. Ceci est utile lorsque vous souhaitez faire don de cibles à
le cache, mais vous ne voulez pas vous fier au contenu du cache (par exemple pour la mission-
constructions critiques).

--profil
Générez des horodatages bruts avant et après chaque action.

-R annuaire
--référentiel=annuaire
Spécifiez le répertoire donné en tant que référentiel (voir makepp_repositories pour plus de détails).
Les référentiels sont ajoutés dans l'ordre spécifié sur la ligne de commande, donc le premier
vous spécifiez a la priorité. Tous les fichiers du répertoire (et tous ses sous-répertoires)
sont automatiquement liés au répertoire courant (et sous-répertoires) s'ils sont
nécessaire.

Si vous spécifiez simplement un répertoire après "-R", son contenu est lié au répertoire courant
annuaire. Vous pouvez lier son contenu à n'importe quel endroit arbitraire du système de fichiers en
spécifiant l'emplacement avant un signe égal, par exemple,
"-R subdir1/subdir2=/users/joe/joes_nifty_library".

-r
--pas de règles intégrées
Ne chargez pas les ensembles de règles par défaut. Si cette option n'est pas spécifiée et que la variable
"makepp_no_builtin" n'est pas défini dans le makefile, alors un ensemble de règles pour la compilation
Le code C, C++ et Fortran est chargé pour chaque répertoire.

--rm-vicié
--remove-stale
--remove-stale-files
Ignorez les fichiers obsolètes plutôt que de les traiter comme de nouveaux fichiers source, en les supprimant si
nécessaire afin d'empêcher qu'ils soient lus par une commande de construction. Ce n'est pas
la valeur par défaut car elle supprime des éléments, mais elle est souvent requise pour
bâtiment incrémentiel pour fonctionner correctement.

Par exemple, supposons qu'il existe un xc fichier qui ressemble à ceci :

#inclure "xh"
int main() { renvoie X ; }

Considérez ce makefile :

$(phony par défaut) : x
xh :
&echo "#define X 1" -o $@

À un moment donné, vous modifiez le makefile pour qu'il ressemble à ceci :

CFLAG := -Idir
$(phony par défaut) : x
rép/xh :
&mkdir -p $(dir $@)
&echo "#define X 2" -o $@

Maintenant, si vous construisez à partir de clean, x sort avec le statut 2, mais si vous construisez pendant que l'ancien
./xh le fichier existe toujours et vous ne spécifiez pas "--rm-stale", alors x sorties avec statut
1, car la directive include récupère le fichier d'en-tête généré obsolète.

Si vous construisez avec "--rm-stale", alors ./xh est supprimé et le résultat est le même que
celui d'une construction propre, ce qui est presque toujours une bonne chose.

Notez que si vous construisez dans un référentiel, vous devez d'abord y donner cette option,
car le makepp importateur ne sait pas ce qui pourrait être périmé dans le référentiel.

Les makefiles hérités mettent parfois la règle pour générer un fichier d'inclusion après l'inclusion
déclaration. Mpp fonctionne comme gmake, en rechargeant à la fin du makefile
si besoin. Mais cela signifie que lors d'une reconstruction, il semble vicié au point où il est
nécessaire et sera supprimé. Par conséquent, cette option désactive ce type de rechargement.

-s
--silencieux
--silencieux
Ne faites pas écho aux commandes et n'imprimez pas de messages d'information tels que « Numérisation » ou « Chargement
makefile".

--bac à sable=annuaire
--in-sandbox=annuaire
--inside-sandbox=annuaire
Restreignez cette instance de makepp à un sous-arbre d'un arbre de construction normalement plus grand. Voir
partitionnement en bacs à sable.

--sandbox-avertir
--sandbox-avertissement
Rétrogradez les violations de « in-sandbox » et « dont-read » en avertissements au lieu d'erreurs.
Voir partitionnement en sandbox.

--stop-course
--arrêt en course
Quitter par erreur plutôt que d'avertir uniquement d'une collision d'accès au cache de build qui pourrait
être fixé.

--symlink-in-rep-as-file
--lien symbolique dans le référentiel en tant que fichier
Si un référentiel contient un lien symbolique, alors par défaut ce lien symbolique est
importé en tant que lien, c'est-à-dire que la cible du lien importé n'a pas besoin d'être
identique à la cible du lien symbolique dans le référentiel. Si la
L'option "--symlink-in-repository-as-file" est spécifiée, alors le lien symbolique est
importé comme son fichier cible, c'est-à-dire que le lien importé pointe vers le même
cible comme lien symbolique dans le référentiel. Ceci est utile si la symbolique
lien dans le référentiel était destiné à avoir la sémantique de construction d'une copie.

--traditionnel
--traditionnel-recursion
--fabrication-récursive-traditionnelle
Cette option est présente pour permettre à makepp de fonctionner avec d'anciens makefiles qui utilisent récursif
faire abondamment, en particulier avec des options variées. Par défaut, make récursif est
mis en œuvre par un sous-processus qui communique avec le processus parent ; la construction est
effectivement fait par le processus parent. Cela permet certaines des fonctionnalités intéressantes de makepp comme
référentiels pour travailler avec des appels make récursifs. Cependant, cette technique va
ne fonctionne pas si vous utilisez différentes options de ligne de commande sur différentes invocations de
faire récursif. Avant de l'utiliser, essayez "--hybrid-recursive-make".

L'option "--traditional-recursive-make" rend makepp récursif de la même manière que
le make traditionnel, permettant à plus de makefiles de fonctionner, mais ensuite les référentiels et
les builds parallèles ne fonctionnent pas correctement. Cette option est rarement nécessaire plus, et
makepp vous dira s'il rencontre une construction qui l'exige.

Si vous utilisez cette option, vous obtiendrez des fichiers journaux s'empilant dans les différents répertoires
cela change en. Pour vous en débarrasser uniquement, utilisez "makeppclean --logs --recurse" ou "mppc
-g / D".

-v
--verbeux
Mode verbeux. Explique ce qu'il essaie de construire et pourquoi chaque fichier est construit.
Cela peut être utile si vous pensez qu'un fichier est reconstruit trop souvent.

Cette option prend en fait ce qui serait écrit dans le fichier journal et l'affiche sur
l'écran. Il est généralement plus facile d'exécuter makepp puis de regarder la sortie de
makepplog, qui permet diverses sélections et quelques réécritures.

-V
--version
Imprimez le numéro de version.

--bac à sable virtuel
Ne réécrivez pas les informations de build des fichiers qui n'ont pas été créés par ce processus makepp. Voir
partitionnement en bacs à sable.

-W nom de fichier
--assume-nouveau=nom de fichier
--nouveau-fichier=nom de fichier
--et-si=nom de fichier
Prétend que le fichier spécifié a changé, de sorte que toutes les cibles qui dépendent de ce fichier
sera reconstruit. Le fichier lui-même n'est pas nécessairement modifié (il peut ou non être
reconstruit, selon qu'il est à jour par rapport à ses dépendances), mais
tout ce qui en dépend pense qu'il a changé. Cela peut être utile pour
déboguer un makefile.

ENVIRONNEMENT

Makepp recherche vers le haut un fichier appelé .makepprc au démarrage et après chaque
Option "-C" ou "-c". Chaque fois qu'il trouve un tel fichier, mais une seule fois par fichier, il lira
le fichier et l'analyser comme des options éventuellement citées sur une ou plusieurs lignes. Contrairement au
option "-A", les options seront analysées par rapport au répertoire où réside le fichier.

Makepp examine les variables d'environnement suivantes :

$FAIREDRAPEAU
Tous les indicateurs de cette variable d'environnement sont interprétés comme des options de ligne de commande avant
toutes les options explicites. Tous les arguments de la ligne de commande sont mis dans cette variable

Notez que la marque traditionnelle utilise également cette variable, donc si vous devez utiliser les deux
make et makepp, vous pouvez envisager d'utiliser "MAKEPPFLAGS".

$MAKEPPFLAGS
Identique à "MAKEFLAGS" en ce qui concerne makepp. Si cette variable n'est pas vide,
alors "MAKEFLAGS" est ignoré. Parfois, cela est utile au lieu de "MAKEFLAGS" si vous
devez utiliser à la fois make et makepp, et vous devez séparer les options.

$MAKEPP_CASE_SENSITIVE_FILENAMES
Makepp tentera de déterminer si son répertoire par défaut est sensible à la casse en
créer un fichier, puis y accéder avec une autre casse. Habituellement, cela fonctionne bien,
tant que tous les fichiers auxquels vous accédez sont sur le même système de fichiers que votre système par défaut
répertoire, vous devriez donc rarement avoir besoin d'utiliser cette option.

Si cette variable est présente dans l'environnement, sa valeur (0 ou chaîne vide pour
false, rien d'autre pour true) remplacera le choix de makepp. Cette variable est principalement
utile sous Windows, si vous souhaitez remplacer le paramètre par défaut de makepp. Si vous ne
traiter les noms de fichiers comme sensibles à la casse, puis makepp convertit tous les noms de fichiers en minuscules,
ce qui provoque des difficultés occasionnelles. (Par exemple, emacs peut ouvrir plusieurs tampons pour
le même fichier.)

Makepp ne prend actuellement pas en charge une construction sur plusieurs systèmes de fichiers, si l'on est
sensible à la casse et l'autre insensible à la casse.

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