makepp_faq - En ligne dans le Cloud

PROGRAMME:

Nom

makepp_faq -- Foire aux questions sur makepp

DESCRIPTION

Vous trouverez ici les instructions d'installation et certains points qui ne ressortent pas clairement du
reste de la documentation. Cela montre des pierres d'achoppement, alors que comment taper des questions sera
se trouve dans le livre de cuisine.

Obtenir A débuté
Où à Télécharger?

Makepp est hébergé sur SourceForge et peut être téléchargé en tant qu'archive de code source ou en tant que
paquet d'installation pour Debian . Deb Linux basé ou . Rpm Linux basé sur
http://sourceforge.net/projects/makepp/files/

Comme des tonnes de logiciels Perl, makepp peut également être téléchargé à partir du CPAN en cliquant sur le bouton
Lien de téléchargement sur http://search.cpan.org/dist/makepp/

Makepp fait partie de Debian GNU/Linux instable et testing. Cela signifie que vous pouvez l'installer
directement via "apt-get install makepp" ou en le choisissant dans votre outil de package préféré
comme synaptique.

Makepp fait partie d'archlinux et de Gentoo Linux. Notez que les suffixes spécifiques à la distribution comme
2.0-1 ou 2.0-r1 n'est pas la release candidate 1, mais la version finale 2.0.

Pouvez I Essai it sans installer ?

Oui, si vous voulez essayer makepp sur vos propres makefiles, placez soit le répertoire où vous
décompressé dans votre chemin, ou bien exécutez-le explicitement comme ceci, avec un absolu ou
chemin relatif vers makepp :

perl /où/vous/avez/déballé/it/makepp

Comment la à choisissez perl version?

Vous devez avoir Perl 5.8 ou plus récent quelque part sur votre système. Par défaut tout est désinstallé
les scripts utiliseront le "perl" dans votre chemin. Mais vous pouvez les exécuter avec une instance explicite
de perl. Le lanceur de test et l'installation exécuteront tout avec cette même instance.

/chemin/vers/perl /où/vous/avez/déballé/it/makepp

Dans le cas où un script ne reconnaît pas correctement avec quel "perl" il est exécuté, vous pouvez
aidez-le en lui indiquant le chemin vers la même instance de perl via la variable "PERL":

PERL=/chemin/vers/perl /chemin/vers/perl /où/vous/avez/déballé/it/makepp

Cela peut aussi être une instance à rechercher dans votre chemin, s'il ne contient pas de
séparateur de répertoire :

PERL=perl5.16.2 perl5.16.2 /où/vous/unpacked/it/makepp

Comment la à installer?

Il y a deux façons d'installer, qui conduisent au même résultat :

configurer (alias config.pl)
Cela permet une installation de style traditionnel :

./configure && make test && make install

La seule différence entre les deux est que "configure" n'est pas un script Perl, donc vous
ne peut pas dire "perl configure", alors que vous pouvez utiliser toutes les variantes ci-dessus comme "perl
config.pl". Les options valides sont :

-b, --bindir=/chemin/vers/installation/bin
Où vont les binaires (par défaut : préfixe/ bin). Les binaires de Makepp ne sont que Perl
scripts afin qu'ils soient indépendants de l'architecture. Si vous donnez cette option, mais non
"--prefix", il supprimera / bin en déduire un préfixe pour les autres valeurs par défaut.

-d, --datadir=/chemin/vers/installation/partage/makepp
Où installer les fichiers de bibliothèque de makepp (par défaut : préfixe/share/makepp).

-f, --findbin=relatif/chemin/vers/datadir/from/bindir
Où trouver les bibliothèques relatives aux exécutables, ou 'aucun' (par défaut) à trouver
les dans répertoire de données.

-h, --réphtml=/chemin/vers/installation/partage/html
Où va la documentation HTML (par défaut : préfixe/doc/makepp si préfixe/doc
existe, sinon répertoire de données/html), ou 'aucun' si vous ne voulez pas qu'il soit installé.

-m, --mandir=/chemin/vers/homme
Où les pages de manuel doivent résider (par défaut : préfixe/share/man s'il existe, sinon
préfixe/man), ou 'none' si vous ne voulez pas qu'ils soient installés.

--makefile=/chemin/vers/Makefile
Spécifiez l'emplacement où vous pouvez écrire le Makefile (par défaut : .). Contrairement à l'autre
options, qui sont mémorisées pour l'étape d'installation suivante, ce fichier est créé
immédiatement.

-p, --préfixe=/chemin/vers/installation
Spécifiez l'emplacement où vous souhaitez tout installer (par défaut : / Usr / local). Tout
les autres chemins sont par défaut relatifs à celui-ci.

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

Si vous souhaitez effectuer une installation de maquette dans un répertoire de destination pour emballer le vôtre
distribution, vous pouvez donner un paramètre supplémentaire à la dernière commande :

make DESTDIR=/temporary/destdir installer

installer.pl
Il s'agit du backend qui effectue l'installation proprement dite. Vous pouvez l'appeler directement :

./install.pl bindir datadir mandir htmldir findbin destdir

Les paramètres sont facultatifs et correspondent aux options de la section précédente.
Vous êtes invité à indiquer ceux que vous ne fournissez pas, à l'exception du dernier, qui n'est pas
normalement nécessaire.

Makefile.PL
Le fichier coutumier Makefile.PL n'est actuellement présent que pour des raisons techniques. Ce
vont pas vous aider à installer. Par conséquent, hélas, vous ne pouvez pas utiliser des outils comme "cpanm" pour
installer en une seule fois.

Sur certains systèmes, le "perl" que vous appelez peut être un lien symbolique vers un
version "perl5.mn". Dans ce cas perl ne voit que celui-là, et l'utilisera donc pour
installer contre. Si vous ne le souhaitez pas, utilisez la variable "PERL" comme décrit ci-dessus. Si
vous installez avec la deuxième variante, c'est à dire juste le nom de l'exécutable sans slash,
les scripts installés rechercheront toujours celui-ci via "/ usr / bin / env". Cela les rend
un tout petit peu plus lent à démarrer, pour une plus grande flexibilité.

Pourquoi Choisir ne installation parole autorisation refusé?

Si vous souhaitez installer dans un répertoire système comme / usr, / Usr / local or /opter, vous pouvez seulement
faites-le si vous exécutez l'installation en tant qu'utilisateur root. Sur de nombreux Unices, vous pouvez exécuter une commande comme
root, en ajoutant "sudo" à celui-ci, et selon le système entrant soit la racine
mot de passe, ou le vôtre, comme demandé.

Ceci n'est pas nécessaire pour l'étape préparatoire "configure" ou "config.pl" qui
écrit un Makefile dans le répertoire courant.

Se construisent Questions
Organisateur Ce que sommes-nous sans importance cibles?

Makepp se souvient des dépendances de chaque fichier. Si l'un d'entre eux doit être reconstruit,
sera fait avant la nouvelle numérisation. Mais si la construction échoue, l'analyse réussit, car
le fichier n'est même plus nécessaire, alors à la fin l'échec sera signalé comme
sans importance. (La construction ne doit pas être tentée, à la place, laissez la nouvelle analyse faire ces
construit qu'il trouve nécessaire, mais cela se produit dans un endroit différent, ce serait donc
difficile.)

Pourquoi Choisir ne it courir ceci. exclure 3 fois?

GNU make n'a pas de règles multi-cibles de style makepp. Au lieu de cela, il interprète cela comme un raccourci
pour trois règles distinctes :

abc:
écho $@
toucher abc

Cependant, il ne vérifie pas pourquoi un fichier est là. Si un fichier existe (et est plus récent que n'importe quel
dépendances) il est heureux. Celui des trois fichiers qui est construit en premier, fournit le
deux autres, donc cela se comporte un peu comme une règle multicible - mais peut provoquer une course
conditions dans des builds parallèles.

Une règle similaire aurait pu être :

abc:
touchez $@

Gmake exécute en effet celui-ci une fois par fichier requis. Sans savoir ce que fait la commande
(il peut s'agir d'un script qui crée en interne des fichiers), les deux cas ne peuvent pas être facilement
mis à part par makepp.

Ainsi, en tant que solution de secours spéciale pour la compatibilité, si une action de règle multi-cible ne mentionne que les anciens
style $@ et ni le nouveau style "$(output)" ni "$(target)" ni leurs formes plurielles, c'est
traités comme des règles distinctes. Cela signifie cependant l'exécuter à plusieurs reprises, car makepp ignore
des fichiers apparaissant de manière aléatoire pour lesquels il n'a pas de métadonnées.

Pourquoi Choisir ne it se plaindre qui a créée filet is faux?

Si vous avez une commande qui continue de fonctionner de manière asynchrone, après qu'elle soit revenue avec un
code de retour de succès, makepp remarquera que le fichier promis est manquant et se plaindra. Cette
peut également se produire généralement sur certains systèmes de fichiers réseau, qui peuvent n'écrire physiquement que
quelques secondes plus tard.

Si vous ne pouvez pas éviter une situation aussi insatisfaisante, vous pouvez demander à makepp d'être négligent
à propos de cette vérification avec l'option "--gullible". Mais alors la commande suivante qui dépend de
le fichier produit peut toujours échouer.

Pourquoi Choisir ne it recréer fichiers inutilement ?

J'ai observé cela sur NFS, où en raison de la mise en cache de l'attribut de fichier, l'horodatage du
le fichier produit n'était pas encore celui qu'il avait finalement. Lors de la prochaine exécution, makepp a remarqué le
différence et considérait le dossier indûment modifié. Cela a été résolu avec une option de montage
de "acregmin=0", rendant les attributs immédiatement visibles.

Cela peut également se produire avec les référentiels, par exemple si quelqu'un d'autre a intégré le référentiel
avec "umask 066" ou en utilisant un compilateur qui interdit aux autres de lire le fichier produit.
Cela se produira également si le référentiel ou votre arbre de construction partage un chemin commun
préfixe avec quelques dépendances (par exemple /opt/référentiel et /opt/un outil, dans quel cas
makepp se souviendra du chemin une fois comme relatif, et une fois comme absolu, ayant l'air d'avoir changé
dépendances.

Le le C source filet or le objet filet dépendre on en-têtes ?

Cela dépend de votre point de vue. Si un prototype dans un en-tête change, le programmeur peut avoir
pour adapter le code source. Donc de ce point de vue il y a une dépendance.

Mais pour la construction, cela n'a aucune importance. Ici, les sorties dépendent des entrées.
Si un fichier d'en-tête change, cela peut affecter le fichier objet (par exemple, ajout de paramètres avec
valeurs par défaut, que le programmeur peut ignorer, mais pas le compilateur). Donc de makepp
point de vue, seul le fichier objet produit dépend des en-têtes, c'est-à-dire qu'il doit être reconstruit lorsque
ceux-ci changent.

Divers
Pourquoi Choisir ne makepp sélectivement détecter dépendances ?

Dans cette règle, pourquoi makepp fait-il sortie dépendre de entrée1, mais pas sur entrée2?

sortie:
zcat sortir
zcat entrée2 >>sortie

Il existe trois niveaux de numérisation. Le premier est le lexer, qui essaie de comprendre le
Shell fait partie de l'exécution. C'est-à-dire quelles commandes sont appelées et quelles redirections d'E/S
prend place. Cela remarque entrée1 et sortie (même s'il n'avait pas été déclaré cible de
cette règle).

L'étape suivante concerne les analyseurs de commandes. Makepp en a quelques-unes pour les commandes de compilation typiques.
Ceux-ci vérifient les options de la ligne de commande pour comprendre ce que la commande fera. Dans le
processus, ils récupèrent les dépendances comme les bibliothèques ("cc -llib"), incluent les chemins ("cc -Idir")
et les fichiers d'entrée. La tâche d'un parseur "zcat" serait de savoir que "-S" prend un
argument, mais tous les autres mots non optionnels sont des noms de fichiers (éventuellement suffixés par .gz), Et
que "--" termine les options. Hélas, il n'y a pas un tel parseur, pas plus que pour des centaines d'autres
les commandes.

La troisième étape pour certaines langues est l'analyse des fichiers d'entrée, pour détecter les inclusions comme
dépendances supplémentaires. Cela ne s'applique pas à cet exemple.

Comment la Vous pouvez I déboguer makepp ?

Vous pouvez mettre "$(print )" autour d'une expression suspecte. Cela renvoie le inchangé
expression, tout en l'imprimant comme effet secondaire.

Vous pouvez vider le makefile du répertoire actuel (multiplier après "-C" si vous le souhaitez) avec le
Option "--dump-makefile=file", pour voir comment makepp le voit.

Makepp écrit un journal de tout ce qu'il fait et pourquoi. Vous pouvez regarder cela avec makepplog,
mppl ou makeppgraph, mppg. Vous pouvez le rendre plus détaillé en définissant l'environnement
variable "MAKEPP_DEBUG".

Makepp enregistre tout ce qu'il sait sur un fichier, pour une réutilisation lors de la prochaine exécution. Même s'il faut un certain
compréhension des composants internes de makepp, vidage avec makeppinfo, mppi pour un ou plusieurs
fichiers, donne généralement une idée de ce qui ne va pas. "MAKEPP_DEBUG" fournit en plus le
"RÈGLE_SOURCE".

Si vous vous sentez aventureux, utilisez makepp de cvs. Cela inclut des modules supplémentaires qui
connectez-vous à "perl -d" pour mieux afficher les composants internes de makepp.

Is it sécuritaire à utiliser?

Oui, il fera exactement ce que disent vos makefiles (ce que de nombreux programmeurs ont du mal à
comprendre, car l'inférence basée sur des règles est très différente de la plupart des paradigmes de programmation).

Et aucune, si vous ne faites pas confiance aux makefiles que vous avez, certainement pas ! Un makefile est un drôle
type de script, dont le but est d'exécuter des commandes censées modifier votre
système de fichiers. Makepp n'a aucun moyen de vérifier le mal qu'ils feront.

Pire, il y a toujours des syntaxes d'exécution, qui sont exécutées même avec "--dry-run" (qui
n'exécute pas les règles, mais évalue tout le reste). Cela pourrait être quelque chose comme
ce:

bad_boy := $(shell rm *)

Externe les outils
Pouvez I utilisé cc -M or gcc -MM ?

La reponse courte est oui. La réponse longue est qu'ils ont l'avantage de connaître les
effet de même la dernière option étrange du compilateur, et sous-inclus cachés dans certains compilateurs
répertoire interne, où makepp n'est que très proche. L'inconvénient est qu'ils
n'ont aucune idée des règles de construction, elles ne peuvent donc pas dépendre de manière fiable des fichiers à construire,
qui comprend les fichiers à récupérer à partir d'un référentiel. Et ils ne sont pas extensibles à
d'autres langues, comme le scanner de makepp. Habituellement, vous êtes au moins aussi bien loti, pas
recours à ces outils.

Néanmoins, certains compilateurs peuvent produire cela comme un sous-produit. Si vous préférez utiliser ceci
voir :inclure.

Pouvez I utilisé CCache, Cache de compilation or cachecc1 ?

La reponse courte est oui. La réponse longue est que ces programmes doivent répéter le travail
makepp le fait, pour obtenir une empreinte fiable des fichiers. Avec le traditionnel rend cela même
arrive trop tard, car ceux-ci ratent de nombreuses situations appelant à une recompilation. Avec
makepp, il est simplement plus facile d'utiliser le cache de construction intégré, ce qui présente l'avantage supplémentaire
qu'il peut gérer toutes sortes de fichiers.

Notez que le mode direct ccache a un bogue https://bugzilla.samba.org/show_bug.cgi?id=8728
qui ignorera les changements dans les chemins d'inclusion. Cela fait t/makeppreplay.test échouer avec
"mauvais fichier : out". Exportez "CCACHE_NODIRECT=1" pour éviter cela.

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