AnglaisFrançaisEspagnol

Ad


Icône de favori OnWorks

metaconfig - En ligne dans le Cloud

Exécutez metaconfig dans le fournisseur d'hébergement gratuit OnWorks sur Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS

Il s'agit de la métaconfig de commande qui peut être exécutée dans le fournisseur d'hébergement gratuit OnWorks en utilisant l'un de nos multiples postes de travail en ligne gratuits tels que Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS

PROGRAMME:

Nom


metaconfig - un générateur de script de configuration

SYNOPSIS


métaconfig [ -dhkmostvwGMV ] [-L dir ]

DESCRIPTION


Métaconfig est un programme qui génère des scripts Configure. Si vous ne savez pas ce qu'est un
Configurer le script est, veuillez passer à la TUTORIAL section de cette page de manuel. Si tu veux
une description complète (formelle) de la façon d'utiliser métaconfig et ses unités, veuillez consulter le
RÉFÉRENCE section. Ce qui suit est une introduction rapide et une référence pour les connaisseurs
utilisateurs.

Métaconfig fonctionne à partir d'un ensemble de unités qui définissent tout ce que la métaconfig connaît
portabilité. Chaque unité est autonome et n'a pas besoin d'être enregistrée nulle part
autre que par inclusion dans l'annuaire U public ou dans votre annuaire U privé. Si
le package dist (dont fait partie metaconfig) est installé dans LIB, puis le U public
Le répertoire est LIB/dist/mcon/U. Sur cette machine, le répertoire LIB est /usr/share/dist. Ton
Le répertoire U privé, si vous en avez un, se trouve dans le répertoire de niveau supérieur de votre package.
Avant de pouvoir courir métaconfig vous devez faire plusieurs choses :

· Créez un fichier .package dans le répertoire de niveau supérieur du package en exécutant emballer.
Ce programme vous posera des questions sur votre colis et se souviendra de ce que vous lui dites afin que
tous les programmes dist peuvent être intelligents.

· Consultez le Glossaire (dans LIB/dist/mcon) et écrivez vos scripts shell et programmes C
en termes de symboles que metaconfig sait définir. Vous n'avez pas besoin de dire
metaconfig quels symboles vous avez utilisés, puisque metaconfig le découvrira pour vous.

· Générer tous les scripts .SH nécessaires pour écrire des Makefiles ou des scripts shell qui dépendront
sur les valeurs définies par Configure. Il existe un programme appelé faire SH cela vous aidera
convertir un script simple en un modèle script.SH ; quelques retouches devront encore être
effectuée sur le fichier .SH résultant pour déplacer la partie configuration variable dans le
partie supérieure du script (voir les commentaires en ligne générés par faire SH dans votre .SH
fichier).

· Créez un fichier MANIFEST.new dans votre répertoire de niveau supérieur qui répertorie tous les fichiers dans
votre colis. Ce fichier restera privé et ne fera pas partie de la finale
Distribution. (Par commodité, le fichier MANIFEST sera utilisé par métaconfig if
il n'y a pas encore de fichier MANIFEST.new.) Le nom de fichier doit être le premier champ de chaque
ligne. Après quelques espaces, vous pouvez ajouter un court commentaire décrivant votre fichier. Seul
les fichiers sources doivent y être répertoriés. Le dossier spécial patchlevel.h (lequel est
géré et maintenu par les outils de patch -- voir caresse(1)) devrait faire partie du
MANIFEST.new fichier, mais peut être ignoré silencieusement par certains outils. En règle générale,
seuls les fichiers maintenus par RCS doivent y être répertoriés, le patchlevel.h fichier étant
une exception importante.

· En option, vous pouvez créer un fichier MANIFEST, qui sera une version exportée
de votre MANIFEST.nouveau. Ce fichier doit faire partie de la version, c'est-à-dire être répertorié dans les deux
votre MANIFEST.new et MANIFEST lui-même. Un de métaconfig les unités le savent
fichier et forcera Configure à effectuer une vérification de la version, en s'assurant que tous les fichiers
énumérés là font partie de la distribution. Les fichiers MANIFEST et MANIFEST.new doivent
être distincts, pas des liens.

· Copiez tous les fichiers .U que vous souhaitez modifier dans votre répertoire U privé. Tous les fichiers .U
dans votre répertoire U privé sera utilisé de préférence à celui dans le U public
annuaire. Par exemple, une façon de forcer l'inclusion de n'importe quelle unité est de copier le End.U
dans votre répertoire .U et ajoutez le nom de l'unité que vous voulez en tant que dépendance sur
la fin de la ligne ?MAKE:. Certaines unités peuvent UNIQUEMENT être forcées de cette manière, à savoir
ceux de la forme Warn_*.U et Chk_*.U. Vous pouvez également personnaliser certains défauts
Configurez les variables en copiant Myinit.U dans le répertoire U privé de votre package et
définir les variables dans cette unité.

Vous êtes maintenant prêt à courir métaconfig. Cela créera un Configurer fichier, et éventuellement un
config_h.SH (si vos sources utilisent des symboles C). Les fichiers générés seront
automatiquement ajoutés à votre MANIFEST.new si nécessaire. N'oubliez pas de mettre à jour votre
fichier MANIFEST cependant.

Pour créer de nouvelles unités, procédez comme suit :

· Copiez une unité similaire dans un nouveau fichier .U. Le nom que vous choisissez doit être le nom d'un
variable générée par l'unité, bien que ce ne soit qu'une commodité pour vous, pas un
exigence. Il doit comporter 12 caractères ou moins pour éviter de couper les noms de fichiers.
En fait, il devrait probablement être 10 ou moins pour que ceux qui veulent utiliser RCS puissent avoir
a .U,v au bout sans hacher. Metaconfig utilise la casse de la première lettre pour
déterminer si une variable est réellement produite par cette unité, alors ne capitalisez pas votre
nom de l'unité si elle est censée produire une variable shell.

· Modifiez le nouveau fichier .U pour faire ce que vous voulez. La première ligne ?MAKE: indique le
dépendances; avant les deux points de la liste finale toutes les variables définies par cette unité, et
après les deux points finals toutes les variables (ou autres unités) dont dépend cette unité.
Il est très important que ces listes soient exactes. Si une dépendance est facultative et qu'une
valeur par défaut peut être utilisée, vous devez préfixer la dépendance avec un signe '+'. Les
l'unité correspondante ne sera pas chargée pour calculer le symbole, à moins que cela ne soit vraiment nécessaire
par une autre unité.

· Dans la mesure du possible, paramétrez votre unité en fonction de la variable shell définie sur
?INIT : lignes. Cela déplacera les définitions des variables jusqu'à l'unité Init.U, où
ils peuvent être remplacés par des définitions dans Myinit.U, qui est inclus après Init.U.

· Ajoutez la définition de tous les symboles C souhaités sous forme de lignes ?H:. Une ligne commençant par
?H:?%<: dans le fichier .U sera ajouté à l'éventuel fichier config.h si et seulement si
metaconfig décide que cette unité est nécessaire. Le %< représente le nom de l'unité,
qui se trouve être aussi le nom du fichier (sans .U) si vous avez suivi le
convention. Mettez toujours un commentaire sur chaque ligne ?H: au cas où l'une des variables
substitutions plus tôt sur la ligne commence un commentaire sans le terminer. N'importe quelle coquille
une variable commençant par d_ peut le faire, alors méfiez-vous. Si vous omettez le ?%<:, alors
metaconfig essaiera de deviner le symbole dont la définition est nécessaire avant toute
inclusion dans config.h.

· Ajouter des définitions de glossaire comme ?S : lignes pour les variables shell et ?C : lignes pour C
variables du préprocesseur. Voir une unité actuelle pour des exemples. Il est TRÈS important de
commencez chaque entrée par un nom de symbole justifié à gauche et terminez chaque entrée par un ?C:. ou
?S:. ligne. L'algorithme qui traduit les entrées de symboles du préprocesseur C pour le
Le glossaire en commentaires pour config.h en dépend.

· Assurez-vous que la commande de tous vos ? les lignes ont raison. L'ordre correct est :

?RCS : et ?X : fondamentalement juste des commentaires
?MAKE : dépendances de la métaconfig
?Y : directive d'agencement de l'unité
?S : définitions de shell de glossaire
?C : définitions du glossaire C
?H : définitions de config.h
?M : définitions de confmagic.h
?W : symboles recherchés
?V : symboles visibles
?F : fichiers créés par cet appareil
?T : symboles de shell temporaires utilisés
?D : valeur par défaut des dépendances facultatives
?O : utilisé pour marquer les unités obsolètes
?LINT : indices de métalint
?INIT : initialisations des symboles du shell

Voici un exemple pour montrer l'ordre des lignes et les différents formats autorisés :

?RCS : $RCS-Id$
?RCS : informations sur les droits d'auteur
?RCS : $RCS-Log$
?X:
?X : Un exemple artificiel
?X:
?MAKE:d_one deux : trois + quatre Cinq
?MAKE : -pick ajouter $@ %
?Y:DEFAUT
?S:d_one :
?S : Premier symbole de coque, définit conditionnellement UN.
?S :.
?S:deux:
?S : Deuxième symbole de coquillage, valeur pour DEUX.
?S :.
?CÔNE:
?C : Premier symbole C.
?C:.
?C:DEUX :
?C : Deuxième symbole C.
?C:.
?H:#$d_one UN /**/
?H:#define DEUX "$deux"
?H:#$d_one ONE_TWO "$deux"
?H :.
?M:flip : HAS_FLIP
?M:#ifndef HAS_FLIP
?M:#définir flip(x) flop(x)
?M :#endif
?M :.
?W:%<:one_two
?V:p_un p_deux:p_trois
?F:fichier ./ftest !tmp
?T:var tmp
?D:deux='undef'
?LINT:changer trois
?INIT:two_init='2'
: le code shell implémentant l'unité suit
p_one='un'
p_two='deux'
p_trois=""

Permettez-moi de le répéter une fois de plus : la définition d'unité ci-dessus est un faux un pour montrer seulement le
différentes possibilités. Une telle unité ne servirait à rien de toute façon... Un peu plus
les fonctionnalités avancées ne sont pas décrites ici. Veuillez vous référer au RÉFÉRENCE rubrique pour en savoir plus
information complète.

· Mettre l'unité dans le répertoire U public ou privé selon le cas.

· Rediffusion métaconfig.

· Envoyez votre unité à [email protected] (Raphael Manfredi) pour inclusion dans la copie maître,
si vous pensez que c'est d'intérêt général.

Afin d'ajouter un nouveau programme à localiser :

· Éditez Loc.U, et ajoutez le nom du programme à la fois à la ligne ?MAKE: (entre le
deux deux-points) et à loclist ou trylist (selon que le programme est
obligatoire ou non).

· Réexécutez la métaconfig.

· Envoyez-moi votre unité pour inclusion dans la copie principale, si vous pensez que c'est d'ordre général
intérêt.

Notes pour l'écriture des fichiers .U :

* Utilisez toujours "rm -f" car il existe des systèmes où rm est interactif par défaut.

* N'utilisez pas "set -- ..." car '--' ne fonctionne pas avec tous les shells. Utilisez "définir x ... ;
décalage".

* N'utilisez pas "unset ENV" car unset n'est pas entièrement portable. Dites "ENV=''" à la place.

* Utilisez toujours echo " " (avec un espace) à cause des systèmes Eunice.

* Seule utilisation tester avec -r, -w, -f ou -d car ce sont les seuls commutateurs portables. Dans
en particulier, évitez "test -x".

* N'utilisez que les programmes fournis avec la V7, afin que vous sachiez que tout le monde les possède.

* Utilisez $contains lorsque vous voulez grep conditionnellement, car tous les greps ne renvoient pas un
statut raisonnable. Assurez-vous de rediriger la sortie vers /dev/null, en utilisant '>/dev/null
2>&1'.

* Utilisez "if test" plutôt que "if [...]" car tous les sh ne connaissent pas cette dernière construction.

* Utilisez le script myread pour les entrées afin qu'ils puissent faire des échappements de shell et par défaut
évaluation. La forme générale est

cas "$grimble" dans
'') dflt=452;;
*) dflt="$grimble";;
Esac
rp='Combien de grimbles avez-vous ?'
. ./ma lecture
grimble="$ans"

* Utilisez le script getfile lorsque vous demandez un nom de chemin de fichier afin d'avoir facultatif
~ expansion du nom et vérifications de l'intégrité. Voir l'unité Getfile.U pour une description complète.

* Mettez toujours un

$débutsh

en haut de chaque script généré qui va être lancé ou sourcé par
Configurer.

* Ne supposez jamais des ismes UNIX courants comme le fait qu'un fichier objet se termine par un .o ainsi que
qu'un nom de bibliothèque se termine par .a. Utilisez le $_o ainsi que $_a variables à la place (voir
Unix.U).

* Lorsque vous effectuez un test de compilation-lien-exécution, écrivez-le toujours comme ceci :

$cc $ccflags $ldflags try.c -o essayer $libs

car certains systèmes exigent que les indicateurs de liaison soient spécifiés avant le compilé
target (à l'exception des bibliothèques de liaison de fin).

* Émettez des messages importants sur le descripteur de fichier #4, en utilisant '>&4' pour rediriger la sortie.
Seuls ces messages apparaîtront lorsque le -s l'interrupteur est donné à Configurer sur le
ligne de commande (mode silencieux).

* Essayez toujours de déterminer si une fonctionnalité est présente de la manière la plus spécifique - ne
dites "if bsd" quand vous pouvez grep libc. Il existe de nombreux systèmes hybrides et
chaque caractéristique doit se tenir debout ou tomber d'elle-même.

* Essayez toujours de déterminer si une caractéristique est présente de la manière la plus générale, afin que
d'autres forfaits peuvent utiliser votre unité.

* En cas de doute, définissez une valeur par défaut et demandez. Ne supposez rien.

* Si vous pensez que l'utilisateur a tort, tenez compte du fait qu'il a peut-être raison. Pour
exemple, il pourrait exécuter Configure sur un système différent de celui qu'il va utiliser
le produit final sur.

Metaconfig réserve les noms suivants dans votre répertoire, et si vous utilisez un tel nom il
peut être écrasé ou avoir d'autres effets imprévus :

.MT/*
Configurer
recherché
Obsolète
configurer
config_h.SH
confmagic.h
U/*
MANIFESTE.nouveau

De plus, Configure peut supprimer ces noms dans le répertoire dans lequel il est exécuté :

UU/*
config.sh
config.h

OPTIONS


Les options suivantes sont reconnues par métaconfig:

-d Activez le mode de débogage. Pas vraiment utile sauf si vous déboguez métaconfig
elle-même.

-h Imprimer le message d'aide et quitter.

-k Conservez le répertoire temporaire, afin que vous puissiez examiner les fichiers de travail utilisés par
métaconfig pour construire votre Configurer scénario. Utile uniquement lors du débogage du
unités.

-m Supposons beaucoup de mémoire et d'espace d'échange. Cela accélérera la recherche de symboles dans
fichiers source par une quantité de temps significative, au détriment de la mémoire
consommation...

-o Mappez les symboles obsolètes sur les nouveaux. Utilisez ce commutateur si vous en avez encore
symboles obsolètes dans votre code source et que vous ne voulez pas (ou ne pouvez pas) supprimer
eux pour l'instant. Les symboles obsolètes sont par ailleurs ignorés, bien que
vous donnera un avertissement de métaconfig.

-s Activez le mode silencieux.

-t Tracez les symboles au fur et à mesure qu'ils sont trouvés.

-v Activez le mode détaillé.

-w Supposons que le fichier recherché est à jour. Cela sautera le temps et la mémoire
phase consommatrice d'analyse du code source, à la recherche de symboles connus. Utilise le
uniquement lorsque vous savez que votre fichier source n'a pas changé par rapport au
piscine de métaconfig symboles utilisés.

-G Fournir également un GNU configurer-comme le front end généré Configurer
script, à inclure également dans la distribution. Ceci n'est qu'un emballage
autour de la Configurer script naturellement, mais il permet aux personnes familiarisées avec le
Outil GNU pour ne pas être perdu face à une nouvelle distribution.

-L dir Remplacer l'emplacement par défaut de la bibliothèque. Normalement utile uniquement pour la métaconfig
mainteneurs à utiliser localement les unités en cours de développement au lieu des
celles accessibles au public. Les dir spécifié est celui qui contient les unités
U répertoire.

-M Permettre la production d'un confmagic.h fichier pour remapper automatiquement certains bien-
symboles connus à une autre alternative, comme bcopie() en cours de remappage
de manière transparente à memcpy() lorsqu'il n'est pas disponible. Cette option est activée
automatiquement lorsqu'un confmagic.h fichier existe dans le répertoire de niveau supérieur.
Supprimez simplement ce fichier si vous souhaitez désactiver cette option de façon permanente.

-V Imprimer le numéro de version et quitter.

TUTORIAL


Cette (longue) section est une introduction à métaconfig, dans lequel nous apprendrons tous les
bases. Si vous savez déjà utiliser métaconfig, vous pouvez passer en toute sécurité au suivant
.

Vue d’ensemble
Habituellement, lorsque vous souhaitez obtenir un package source à compiler sur une plate-forme donnée, vous avez
pour éditer le Makefile principal (en supposant qu'il y en ait un !), choisissez un compilateur C, assurez-vous de
avoir les bibliothèques appropriées, puis lancer le faire commander. Si le colis est raisonnablement
bien écrit, il compilera (sans qu'un avertissement soit une option :-). En soi, le dernier
phrase est une vraie performance, puisque compte tenu de la variété des plateformes UNIX disponibles aujourd'hui
et la diversité des saveurs, cela signifie que l'auteur de l'emballage a approfondi
difficulté à trouver les bons choix compte tenu d'un essai standard, de deviner et de déconner
autour avec le système comprend et types.

Cependant, malgré tout son talent, l'auteur ne peut pas savoir qu'un système a un
appel système interrompu, ou qu'une structure système manque d'un champ par ailleurs standard, ou
simplement si un fichier d'inclusion donné existe ou non. Et je ne considère pas l'implicite
hypothèses, comme le type renvoyé par le malloc () fonction ou la présence du
Renommer() appel système pour n'en nommer que quelques-uns. Mais cette connaissance est nécessaire pour atteindre un réel
portabilité.

Maintenant, ne nous abusons pas. L'utilisation de ces informations nécessite de plus grandes compétences, mais elle peut
conduire à des programmes plus portables car il est ensuite écrit de manière indépendante du système
et repose uniquement sur le fait qu'une hypothèse est vraie ou fausse sur un système particulier,
chaque hypothèse étant indépendante les unes des autres. C'est-à-dire qu'on ne dit pas : on est sur un
système BSD ou nous sommes sur un système USG. C'est trop flou de toute façon de nos jours. Non, nous voulons
dire au code source : ce système n'a pas le Renommer() appel système et malloc ()
renvoie un (annuler *) valeur.

Metaconfig est un outil qui vous permettra de faire exactement cela, avec l'avantage supplémentaire de ne pas
devoir éditer manuellement le Makefile si tout se passe bien. En exécutant métaconfig, vous créez un
script shell nommé Configurer. Beaucoup d'efforts ont été consacrés au script Configure
internes pour s'assurer qu'il fonctionnera sur 99% des shells existants disponibles à ce jour
l'écriture. Configure va sonder le système cible, poser des questions en cas de doute et
rassembler toutes les réponses dans un seul fichier shell, qui à son tour peut être utilisé pour
générer automatiquement des fichiers Makefile et C include configurés.

Il n'y a qu'un ensemble limité (mais assez grand) de symboles disponibles pour vos scripts shell
et les programmes C. Ils sont tous documentés dans le fichier Glossaire. Tout ce que vous avez à faire est d'apprendre
à leur sujet et commencez à les utiliser pour résoudre les problèmes de portabilité et de configuration. Puis,
en exécutant métaconfig, un script Configure approprié sera généré pour votre package.

Le script Configure est composé de plusieurs unités (plus de 300), chaque unité étant
responsable de la définition d'un petit nombre de symboles shell et/ou C. Les unités sont assemblées
ensemble à l'étape finale, en respectant le graphique de dépendance (une unité peut avoir besoin du résultat
de plusieurs autres unités qui sont ensuite placées avant dans le script).

Symboles
Les symboles sont la chose la plus importante dans le métaconfig monde. ce sont les plus petits
entité reconnue, généralement un mot, et peut se voir attribuer une valeur à la fin de la configuration
exécution. Par exemple, le symbole du préprocesseur C HAS_RENAME est une métaconfig symbole que
est assuré d'être défini si, et seulement si, le Renommer() l'appel système est présent. De même,
le $ ranlib La variable shell sera définie sur ':' ou 'ranlib' selon que le
appeler le ranlib programme est nécessaire pour commander un fichier de bibliothèque. Comment cela fonctionne n'est pas
important pour l'instant, ce qui est important est de comprendre que ces symboles reçoivent un life
(c'est-à-dire une valeur) sur Configurer exécution.

L'utilisation de symboles est relativement simple. Dans un fichier source C, vous utilisez simplement le symbole
value, en tant que directive de préprocesseur (par exemple : #ifdef HAS_RENAME) ou, si le symbole
value est une chaîne, directement comme vous utiliseriez une macro en C. Et dans un fichier shell ou un
Makefile, vous pouvez référencer directement un symbole de shell.

En fait, je mens, parce que ce n'est pas complètement aussi magique que le paragraphe précédent
pourrait sonner. Dans un fichier C, vous devez inclure le fichier Configure config.h fichier, et
vous devez envelopper votre script shell ou Makefile dans un fichier .SH et vous pouvez référencer le shell
symbole uniquement dans la partie de substitution de variable de ce fichier .SH. Plus à ce sujet plus tard.

Identifier Fichiers
Les symboles peuvent n'apparaître que dans un ensemble limité de fichiers source, car métaconfig sera seulement
scannez-les lorsque vous recherchez des symboles connus, en essayant de déterminer de quelles unités il aura besoin.
Vous pouvez utiliser des symboles C dans les fichiers source C, c'est-à-dire les fichiers avec un .c, .h, .y or .l extension et
les symboles shell ne sont recherchés que dans les fichiers .SH.

Afin d'obtenir la valeur d'un symbole, un fichier C doit inclure le config.h
fichier, qui est produit par Configurer lorsque les symboles C sont présents. Et les fichiers .SH sont exécutés
via un shell, produisant un nouveau fichier. Cependant, dans la partie supérieure du fichier .SH, le
spécial config.sh fichier (également produit en exécutant Configurer) est sourcé et variable
des substitutions s'appliquent. Réellement, config.h est produit en exécutant le métaconfig-produite
config_h.SH fichier, encore une fois en utilisant la substitution de variable. Nous allons donc examiner cela un
un peu plus près puisque c'est le cœur de l'ensemble paramétrage schème...

Variable Substitution
Il existe une construction shell appelée ici document qui permet à une commande de prendre une entrée
spécifié dans le script lui-même. Cette entrée est interprétée par le shell comme un double
chaîne entre guillemets ou une seule chaîne entre guillemets selon la forme du document ici
spécification.

Pour spécifier un document ici, le jeton '<<' est utilisé, suivi d'un identifiant unique. De
puis activé, les lignes de script restantes forment l'entrée de la commande, jusqu'à ce que le ici
document se trouve sur une ligne par lui-même. Substitution de shell (y compris la variable shell
substitutions) est effectuée à moins que l'identifiant ne soit entouré de guillemets simples. Par exemple:

var='premier'
tar='seconde'
echo "--> premier ici document :"
chat <
var='$var'
tar='$tar'
MOE
echo "--> deuxième ici document :"
chat <<'EOM'
écho $var
écho $tar
MOE
echo "--> fin."

produira, lorsqu'il sera exécuté dans un shell :

--> premier document ici :
var='premier'
tar='seconde'
--> deuxième document ici :
écho $var
écho $tar
--> fin.

Le premier document ici a son contenu interprété tandis que le second est sorti tel quel.
Les deux sont utiles dans un script .SH, comme nous allons le voir.

En utilisant .SH Scripts
Un script .SH est généralement produit en exécutant le MarqueSH script autre un fichier existant,
transformer filet en fichier.SH. Prenons un seul exemple. Voici un petit script
(appelons-le taille int) qui imprime un seul message, la taille du int type de données en C.
Malheureusement, il contient la valeur câblée, ainsi :

#!/ Bin / sh
taille int='4'
echo "Sur cette machine, le type int est $intsize bytes"

Courons faire SH dessus en tapant 'faire SH taille int'. Nous obtenons un seul tailleint.SH déposer cela
ressemble à ça:

cas $CONFIG dans
'')
si test -f config.sh; alors TOP=.;
elif test -f ../config.sh; alors TOP=..;
elif test -f ../../config.sh; alors TOP=../ ..;
elif test -f ../../../config.sh; alors TOP=../../..;
elif test -f ../../../../config.sh; alors TOP=../../../..;
d'autre
echo "Impossible de trouver config.sh."; sortie 1
fi
. $TOP/config.sh
;;
Esac
: Cela force les fichiers SH à créer une cible dans le même répertoire que le fichier SH.
: C'est pour que make depend sache toujours où trouver les dérivés SH.
cas "$ 0" dans
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
Esac
echo "Extraction de taille int (avec substitutions de variables)"
: Cette section du fichier comportera des substitutions de variables.
: Déplacez tout ce qui a besoin de sous-marins de configuration de !NO!SUBS! section à !GROK!THIS!.
: Protégez tous les signes dollar et backticks que vous ne voulez pas interpréter
: en mettant une barre oblique inverse devant. Vous pouvez supprimer ces commentaires.
$spitshell >intsize <
$débutsh
!GROK!CE!

: Dans les dollars suivants et les backticks n'ont pas besoin de la barre oblique inverse supplémentaire.
$spitshell >>intsize <<'!NO!SUBS!'
taille int='4'
echo "Sur cette machine, le type int est $intsize bytes"
!NON!SUBS!
chmod 755 taille int
$eunicefix taille int

La première partie de ce script (dans le maisons déclaration) essaie de localiser le config.sh
fichier, afin de le sourcer. Les $CONFIG variable est faux par défaut, par vrai quand
config.sh a déjà été sourcé (ce qui serait le cas si ce fichier était exécuté depuis
dans les Configurer lui-même, mais ne confondons pas le problème ici).

Une fois que le config.sh a été des sources, tous les symboles shell définis par Configurer
ensemble. Nous savons atteindre une seconde instruction case, utilisée pour changer le répertoire courant si un
chemin être utilisé pour atteindre ce programme (par exemple si nous avons dit 'sh ../scripts/intsize.SH', nous
courrait d'abord 'cd ../scénarios' avant de continuer). Si vous ne comprenez pas cela, ne
s'inquiéter pour ça.

Voici les choses intéressantes. Ce script utilise le $broche variable, et ce n'est pas
quelque chose que nous savons... encore. Si vous parcourez le fichier Glossaire, vous verrez que
c'est une variable connue par métaconfig. Si vous intégrez ce fichier à votre distribution
(en l'incluant dans le fichier MANIFEST.new, nous y reviendrons plus tard) et lancez
métaconfig, puis le Configurer le script déterminera une valeur appropriée pour cette variable
et il sera mis en config.sh. De même pour $débutsh et le mystérieux $eunicefix at
la fin. Dans un système raisonnable, la partie pertinente de config.sh ressemblerait à ceci:

spitshell='chat'
startsh='#!/ Bin / sh'
eunicefix=':'

Ah ! Nous y arrivons. Maintenant, cela semble familier. Nous sommes confrontés à un seul cat commande dont
l'entrée provient d'un document à interpolation variable ici et dont la sortie est redirigée vers
taille int. La valeur sera celle de $débutsh, c'est à dire '#!/ Bin / sh'. Bien jusqu'ici.

Ensuite, nous atteignons la deuxième expansion du document ici, pour obtenir le reste du script. Cette
temps, le symbole du document ici est entouré de guillemets simples afin que le contenu soit
joint mot à mot au taille int déposer. Donc, en exécutant 'sh tailleint.SH', nous obtenons le
sortie suivante :

Extraction de intsize (avec substitutions de variables)

et en regardant le fichier intsize produit, on voit :

#!/ Bin / sh
taille int='4'
echo "Sur cette machine, le type int est $intsize bytes"

c'est exactement ce que nous avions au début. Pour l'instant, c'est une procédure sans opération...
Mais quelle merveille ! Il se trouve (pure coïncidence, croyez-moi !), que métaconfig sait
sur l' $intsize symbole de la coquille. En déplaçant l'initialisation de intsize vers la variable-
zone interpolée du script .SH et l'initialiser avec le Configurer-valeur calculée,
et en supprimant les commentaires désormais inutiles ajoutés par faire SH, on a:

cas $CONFIG dans
'')
si test -f config.sh; alors TOP=.;
elif test -f ../config.sh; alors TOP=..;
elif test -f ../../config.sh; alors TOP=../ ..;
elif test -f ../../../config.sh; alors TOP=../../..;
elif test -f ../../../../config.sh; alors TOP=../../../..;
d'autre
echo "Impossible de trouver config.sh."; sortie 1
fi
. $TOP/config.sh
;;
Esac
cas "$ 0" dans
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
Esac
echo "Extraction de taille int (avec substitutions de variables)"
$spitshell >intsize <
$débutsh
intsize='$intsize'
!GROK!CE!

$spitshell >>intsize <<'!NO!SUBS!'
echo "Sur cette machine, le type int est $intsize bytes"
!NON!SUBS!
chmod 755 taille int
$eunicefix taille int

Bien sûr, l'exécution de ce script via un shell produira à nouveau le même script. Mais si
nous courrons Configurer sur une machine où un int est stocké sous la forme d'une quantité de 64 bits, config.sh sera
set taille int à 8 et le taille int script portera la bonne valeur et affichera :

Sur cette machine, le type int est de 8 octets

qui est correct. Toutes nos félicitations! Nous venons de configurer un script shell !!

Produire config.h
Nous pouvons maintenant jeter un oeil à la façon config.h est produit à partir de config_h.SH. Nous savons que
pour le running Configurer produit un config.sh script (comment cela est fait exactement n'est pas strictement
pertinent ici, mais pour les curieux, c'est une autre substitution de document ici au sein
Configurer lui-même). Les config_h.SH lui-même est construit par métaconfig à la fois
Configurer est, à condition que vous utilisiez au moins un symbole C dans vos sources.

Jetons un coup d'œil au hasard config_h.SH fichier pour voir ce qui se passe réellement :

cas $CONFIG dans
'')
si test -f config.sh; alors TOP=.;
elif test -f ../config.sh; alors TOP=..;
elif test -f ../../config.sh; alors TOP=../ ..;
elif test -f ../../../config.sh; alors TOP=../../..;
elif test -f ../../../../config.sh; alors TOP=../../../..;
d'autre
echo "Impossible de trouver config.sh."; sortie 1
fi
. $TOP/config.sh
;;
Esac
cas "$ 0" dans
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
Esac
echo "Extraction de config.h (avec substitutions de variables)"
sed < config.h -e 's!^#undef!/define!' -e 's!^#un-def!#undef!'
/*
* Ce fichier a été produit en exécutant le script config_h.SH, qui
* obtient ses valeurs de config.sh, qui est généralement produit par
* exécuter Configure.
*
* N'hésitez pas à modifier tout cela en fonction des besoins. Notez, cependant,
* que l'exécution de config.h.SH à nouveau effacera toutes les modifications que vous avez apportées.
* Pour un changement plus permanent, éditez config.sh et réexécutez config.h.SH.
*/

/* Heure de configuration : $cf_time
* Configuré par : $cf_by
* Système cible : $myuname
*/

#ifndef _config_h_
#define _config_h_

/* bcopie :
* Ce symbole est mappé sur memcpy si la routine bcopy() n'est pas
* disponible pour copier des chaînes.
*/
/* HAS_BCOPY :
* Ce symbole est défini si la routine bcopy() est disponible pour
* copier des blocs de mémoire. Vous ne devez pas utiliser ce symbole sous
* circonstances normales et utilisez bcopy() directement à la place, ce qui
* sera mappé sur memcpy() si bcopy n'est pas disponible.
*/
#$d_bcopy HAS_BCOPY /**/
#ifndef HAS_BCOPY
#ifdef bcopie
#un-def bcopie
#endif
#define bcopy(s,d,l) memcpy((d),(s),(l)) /* mappé sur memcpy */
#endif

/* HAS_DUP2 :
* Ce symbole, s'il est défini, indique que la routine dup2 est
* disponible pour dupliquer les descripteurs de fichiers.
*/
#$d_dup2 HAS_DUP2 /**/

/* I_STRING :
* Ce symbole, s'il est défini, indique au programme C qu'il doit
* comprendre (systèmes USG) au lieu de (systèmes BSD).
*/
#$i_string I_STRING /**/

#endif
!GROK!CE!

En haut du fichier, nous reconnaissons la construction standard .SH que nous avons déjà
étudié en détail. Vient ensuite l'extraction du fichier lui-même, via un document here avec
substitutions de variables. Cependant, ici, nous n'utilisons pas un simple cat mais un sed à la place, puisque
nous devons faire d'autres modifications à la volée. On verra pourquoi plus tard, alors oublions
à ce sujet en ce moment.

Nous arrivons maintenant au commentaire principal, et le fichier est étiqueté avec l'heure de configuration, le
système cible, etc... (ces variables provenant du config.sh fichier ont été
mis en place par Configurer). Cet en-tête de commentaire est suivi d'une protection '#ifndef' pour protéger
contre les inclusions multiples de ce fichier. Vient ensuite le coeur du dossier...

Cela aide à savoir que $d_* ainsi que $i_* les variables sont définies sur 'Vous permet de définir' ou 'indéfini' par
Configurer, selon qu'une fonction ou un fichier d'inclusion est présent sur le système ou
ne pas. Cela signifie :

#$d_bcopy HAS_BCOPY /**/

la ligne sera étendue à :

#définir HAS_BCOPY /**/

si la variable $d_bcopy est définie sur 'define' ou :

#undef HAS_BCOPY /**/

si $d_bcopy était défini sur 'undef', car la fonctionnalité n'était pas là. Cependant, ce n'est pas
ce qui est écrit dans le config.h dossier en raison de la sed filtre que nous avons déjà vu,
qui transformera la seconde forme en :

/*#définir HAS_BCOPY /**/

C'est un formulaire pratique pour l'édition ultérieure de config.h car il vous suffit de retirer le
'/*' au début si vous voulez écraser Configurerau choix. De même, vous pouvez ajouter un seul
'/*' au début d'une ligne '#define' pour éviter la définition d'un symbole particulier.
C'est pourquoi chaque définition de symbole est protégée par un '/**/' de fin, pour fermer le début
commentaire ouvert par '/*' (les commentaires ne sont pas imbriqués en C).

Maintenant, transformer '#undef' en '/*#define' est bien, mais si nous voulons réellement écrire un
'#undef', nous sommes bloqués... sauf si nous l'écrivons comme '#un-def' et laissons sed corrigez cela à '#undef'
en produisant config.h, ce qui est réellement fait ici.

Le même genre de raisonnement s'applique à ces deux lignes :

#$d_dup2 HAS_DUP2 /**/
#$i_string I_STRING /**/

et en supposant config.sh définit :

d_dup2='définir'
i_string='undef'

nous allons entrer dans le produit config.h:

#définir HAS_DUP2 /**/
/*#définir I_STRING /**/

Clair comme de l'eau courante ? Bon!

Maintenant, il devrait être évident qu'en incluant config.h dans tous vos fichiers source C, vous obtenez
savoir quoi Configurer a deviné sur votre système. En effet, en utilisant ces symboles, vous êtes
l'écriture du code C configuré, car métaconfig saurez que vous avez besoin de ces symboles et
générer un config_h.SH fichier ainsi que tout le code nécessaire dans Configurer à
calculer une valeur appropriée pour eux (en attribuant des valeurs aux variables shell associées).

Fonctionnement Métaconfig
Concentrons-nous sur le métaconfig programme pendant un certain temps pour comprendre comment il utilise ses unités et
votre code source pour produire tous les fichiers de configuration nécessaires. Si vous avez l'intention d'écrire de nouveaux
unités, vous devez avoir une bonne compréhension de l'ensemble du schéma.

S'il n'y a pas de fichier MANIFEST.new, métaconfig essaiera d'utiliser le fichier MANIFEST à la place,
pour plus de commodité. Partout où nous mentionnons MANIFEST.new, cela peut être compris comme MANIFEST
à condition qu'aucun fichier MANIFEST.new ne se trouve à la racine de votre package.

En supposant que votre fichier MANIFEST.new est correctement défini et répertorie tous les fichiers source que vous souhaitez
configurer, et que vous avez exécuté emballer dans votre répertoire source racine pour créer un
.paquet fichier, vous pouvez exécuter métaconfig et vous obtiendrez les éléments suivants :

$ métaconfig
Localisation des unités...
Extraction des listes de dépendances de 312 unités...
Extraction des noms de fichiers (*.[chyl] et *.SH) de MANIFEST.new...
Création d'un fichier Wanted...
Recherche de symboles dans les fichiers .[chyl]...
Recherche de symboles dans les fichiers .SH...
Calcul du graphe de dépendance optimal...
Création d'un fichier make privé...
Détermination des unités chargeables...
Mise à jour du fichier make...
Déterminer l'ordre correct des unités...
Création de la configuration...
Terminé.

La première phase recherche tous les fichiers d'unités (se terminant par .U) dans le répertoire public
d'abord, puis dans votre privé. Si vous copiez un fichier public dans votre répertoire U privé
(c'est-à-dire un répertoire nommé U au niveau supérieur de votre package), il remplacera le public
version. Une fois qu'il a une liste de toutes les unités disponibles, il les analyse et extrait toutes
les ?MAKE : lignes pour connaître les dépendances et les symboles shell connus. Ça aussi
se concentre sur les lignes ?H: pour en savoir plus sur les symboles C et quels symboles shell doivent être
calculé pour obtenir une valeur appropriée pour ce symbole C (nous avons donc un autre niveau de dépendances
ici).

Ensuite, les noms de fichiers appropriés sont extraits des fichiers MANIFEST.new et un recherché le fichier est
build : ce fichier répertorie tous les symboles C et les symboles shell nécessaires pour ce package. Nous
scannez d'abord les fichiers de type C pour les symboles C, puis propagez les dépendances à leur
symboles de coque associés (regroupés à partir de ?H : lignes). Ensuite, les fichiers .SH sont analysés et enfin
tous les symboles de coquillages sont connus.

Un Makefile temporaire est construit et metaconfig essaie de faire tous les symboles de coquillages à voir
quelles commandes (listées sur la deuxième ligne ?MAKE:) sont exécutées, et donc quelles unités sont
vraiment besoin. Les unités facultatives non requises par ailleurs sont supprimées et un deuxième Makefile est
généré. Cette fois, nous connaissons toutes les unités et leurs ordres respectifs, en option
les unités ayant été supprimées et les valeurs par défaut calculées pour leurs symboles de coque. Les
Configurer le script peut alors être généré, avec config_h.SH. Avaient fini.

Conventions
Des conventions appropriées doivent être suivies pour que l'ensemble du processus sonne. il y a un cas
convention pour les unités et une convention de nommage des variables.

Toutes les unités doivent avoir leur première lettre en minuscule, à moins qu'il ne s'agisse d'unités spéciales. Par
spécial, nous voulons dire qu'ils ne définissent pas vraiment de nouvelles variables shell qui peuvent être utilisées par le
utilisateur dans ses fichiers .SH, mais plutôt des unités produisant des scripts ou des variables shell qui doivent
être utilisé en interne par le Configurer scénario. Des exemples typiques sont les Init.U fichier qui est
l'initialisation de la variable principale, ou Ma lecture.U qui produit le ma lecture script utilisé presque
partout dans Configurer lorsqu'une question doit être posée à l'utilisateur.

Les unités non spéciales se subdivisent ensuite en deux groupes distincts : les unités définissant les variables
associé à un symbole C et à des unités définissant leurs propres variables shell. Le premier groupe
est en outre divisé en variables liées aux fichiers d'inclusion (leur nom commence par i_) et
variables liées à d'autres définitions (nom commençant par d_). Le deuxième groupe a
noms se tenant pour lui-même, par exemple cc.U définit le $cc variable shell dont la valeur est
le compilateur C à utiliser.

Des unités spéciales se réservent parfois des variables prédéfinies et renvoient des "résultats"
dans d'autres variables bien connues. Par exemple, le ma lecture script produit par Myread.U
attend l'invite dans $rp, la réponse par défaut dans $dflt et place la réponse de l'utilisateur dans $ans.
Ceci n'est pas documenté dans cette page de manuel : il faut aller voir l'appareil lui-même pour
comprendre quelles variables sont utilisées et comment l'unité doit être utilisée.

En utilisant La Glossaire
Le fichier Glossaire est produit automatiquement par le faire briller script, qui extrait le
informations de ?S:, ?C: et ?MAKE: lignes et les reformate dans un ordre alphabétique
glossaire trié. Il est important de lire le glossaire pour connaître les symboles que vous
autorisé à utiliser. Cependant, le glossaire ne vous dira pas comment les utiliser. Habituellement, c'est
à toi de voir.

Un jour, vous écrirez probablement vos propres unités et vous en saurez assez sur métaconfig
pour le faire rapidement et efficacement. Cependant, n'oubliez jamais de bien documenter votre travail dans
les lignes ?S: et ?C:, ou d'autres personnes ne pourront pas les réutiliser. Souvenez-vous de la
moment où vous n'aviez que le glossaire et cette page de manuel pour commencer.

Conclusion
Maintenant que vous connaissez le métaconfig bases, vous devriez lire le DESCRIPTION section, puis
passer au RÉFÉRENCE section pour en savoir plus sur tous les détails sanglants tels que le permis
syntaxe pour les lignes de contrôle d'unité (lignes commençant par un '?') ou les commandes MAKE distinctes
vous êtes autorisé à utiliser.

RÉFÉRENCE


Cette section documente les éléments internes de métaconfig, essentiellement la syntaxe unitaire, le
unités que vous devez connaître et les fichiers d'indices.

Général Unité Syntaxe
Une unité de métaconfig est divisée en deux parties distinctes. La section d'en-tête (lignes commençant
avec '?') et une section shell (code à inclure dans le Configurer scénario). Il est
possible d'ajouter des commentaires '?X:' n'importe où dans l'unité, mais l'autre '?' lignes (aussi
appelé des bactéries lignes) ont une politique de commande stricte.

Si une ligne de contrôle est trop longue, il est possible d'utiliser une continuation en échappant à la finale
nouvelle ligne avec une barre oblique inverse et continuer sur la ligne suivante (qui devrait alors être en retrait
par des espaces ou des tabulations).

Ce qui suit est une description formelle de chacune des lignes de contrôle. Sauf si mentionné
sinon, l'ordre de cette présentation est l'ordre à utiliser au sein de l'unité.

?RCS : faim texte
A utiliser pour les commentaires RCS, en haut de l'unité.

?X: tous texte
Commentaires généraux. Peut apparaître n'importe où dans l'unité mais doit rester justifié.
Pour les commentaires RCS, veuillez utiliser le formulaire de commentaire ?RCS:.

?FABRIQUER:symbole liste: dépendance liste [+facultatif]
Il s'agit de la première ligne de dépendance. La première symbole liste devrait lister tous les symboles
construit par cette unité (c'est-à-dire dont la valeur est calculée par la section de coque de l'unité).
Les symboles doivent être séparés par des espaces. Si un symbole défini est à usage interne uniquement et
ne doit pas apparaître dans le fichier généré config.sh fichier, il doit être précédé d'un
'+' (à ne pas confondre avec les dépendances optionnelles définies ci-après). La deuxième
partie de la liste (après le milieu ':') est la dépendance de l'unité. Il devrait énumérer tous
les unités spéciales nécessaires, ainsi que tous les symboles utilisés par le shell
la mise en oeuvre. Si un symbole est nécessaire mais que sa valeur de configuration n'est pas critique, il
peut être précédé d'un '+', auquel cas on parle de dépendance conditionnelle : sa
l'unité correspondante sera chargée si, et seulement si, ce symbole est autrement vraiment
voulait; sinon, la valeur par défaut sera utilisée.

?FABRIQUER:languette commander
Il peut y avoir une ou plusieurs lignes de commande après les lignes de dépendance initiales. Celles
les commandes seront exécutées lorsque l'unité veut les charger dans Configurer. Voir
le paragraphe sur les commandes make pour plus d'informations. A noter que le leader languette
caractère est requis avant le commander.

?O:disposition
Déclarez une directive de mise en page pour cette unité. Cette directive peut être l'une des chaînes
top, défaut or bas (le cas n'a pas d'importance, le style recommandé est de les épeler
majuscule). Si omis, défaut est assumé.

Cette directive n'est requise que si vous souhaitez forcer une unité en haut ou en bas
du généré Configurer script, car les dépendances d'unités le permettent. Important
les questions peuvent donc être forcées au début. Au sein d'une même classe de mise en page, les unités
sont triés par ordre alphabétique avec deux cas particuliers pour les unités d_* et i_*, forcés
respectivement en haut et en bas de leurs classes (mais celles-ci doivent appartenir aux
classe par défaut).

Si vous forcez en haut une unité dont les dépendances obligent toutes les autres unités à
le précèdent, vous n'obtenez rien d'intéressant. Par conséquent, cette directive devrait vraiment
être utilisé pour augmenter la priorité de certaines unités interactives qui ne dépendent pas de plusieurs
d'autres symboles visibles par l'utilisateur, comme les questions liées au chemin.

?S :nom_symbole [(obsolète symbole liste)] :
Introduit un symbole de coquillage. Cette première ligne nomme le symbole, éventuellement suivi d'un
liste entre parenthèses et donnant l'équivalent obsolète. Ces obsolètes
les symboles seront remappés sur le nouveau nom_symbole si le -o l'option est donnée à
métaconfig.

?S :tous texte, en Glossaire
Fondamentalement un commentaire décrivant le symbole de la coquille, qui sera extrait par faire briller
dans le fichier Glossaire.

?S:. Ferme le commentaire du symbole de coque.

?C :nom_symbole [~ alias] [(obsolète symbole liste)] :
Introduit un nouveau symbole C. Les alias name est le nom sous lequel le symbole C sera
être contrôlé, c'est-à-dire si le alias symbole est recherché, alors ce symbole C sera écrit
dans l' config_h.SH déposer. Habituellement, l'alias est juste '%<' (représente le nom de l'unité)
et il y a aussi une ligne ?W: mappant un symbole C au alias. Aussi les parties pertinentes
des lignes ?H : sont explicitement protégées par une condition '?%<'. Voir le symbole
paragraphe d'alias pour plus de détails. Le reste de la ligne est l'optionnel
obsolète symbole liste, qui répertorie les anciens équivalents du nouveau nom_symbole.

?C :tous texte, en Glossaire ainsi que config_h.SH
Fondamentalement un commentaire décrivant le symbole C, qui sera extrait par faire briller
dans le fichier Glossaire et par métaconfig into the config_h.SH fichier si le symbole est
voulu (ou si son alias est voulu lorsque l'alias de symbole est utilisé).

?C:. Ferme le commentaire du symbole C.

?H:?symbole:config_h.SH étoffe
Il s'agit de la demande générale d'inclusion dans config_h.SH. La ligne n'est écrite que lorsque
la garde symbole est vraiment recherché. Cette forme générale est nécessaire lorsque le symbole C
l'aliasing a été utilisé. Sinon, si vous utilisez l'un des autres formulaires "standard", le
la garde est effectuée automatiquement par métaconfig elle-même.

?H:#$d_var VAR "$var"
Définit conditionnellement le VAR symbole C dans $var quand est défini sur 'Vous permet de définir'. Implique un
'?VAR:' état de garde, et métaconfig liens automatiquement VAR à ses deux coquilles
dépendances variables (c'est-à-dire les deux $d_var ainsi que $var sera signalé comme voulu if VAR is
utilisé dans les sources C).

?H:#définir VAR [optionnel texte]
définit toujours le VAR symbole C à une certaine valeur. Implique un '?VAR:' état de garde.
Une dépendance shell automatique est faite à l'unité elle-même.

?H:#définir VAR(x,y,z) $var
Définit toujours la macro VAR être la valeur de la $var variable. C'est à la
unité pour assurer $var détient une valeur raisonnable. Une dépendance automatique entre le C
macro VAR et la variable shell est établie, et toute la ligne est gardée par un
implicite '?VAR:'.

?H:#$d_var VAR
Définit conditionnellement VAR if $d_var est réglé sur 'Vous permet de définir'. Implique un '?VAR:' gardiennage
état. Une dépendance shell automatique est générée vers $d_guerre.

?H:#définir VAR "$var"
Attribue une valeur configurée au VAR symbole C. Implique un '?VAR:' état de conservation.
Une dépendance shell automatique est générée pour lier VAR ainsi que $var.

?H:. Ferme le config_h.SH demandes d'inclusion.

?M :C symbole: C dépendances
Introduit une définition magique concernant le symbole C, par confmagic.h, et définit le
symbole de garde pour les autres ?M : définitions. Cette ligne implique silencieusement
'?W:%<:C symbole', c'est-à-dire que l'unité sera chargée dans Configure si le symbole C apparaît
dans les sources C, que la magie soit utilisée ou non. Les dépendances C sont activées
quand la magie est utilisée, afin de forcer leur définition dans config_h.SH. Toutefois, si
la magie est ne sauraient utilisé mais le symbole C apparaît dans la source sans le C nécessaire
dépendances, vous serez averti à chaque fois que le fichier Wanted est construit, car il peut être
un problème de portabilité (et aussi parce que l'unité est inconditionnellement chargée dans
Configurer chaque fois que le symbole C est utilisé, indépendamment des autres ?C : lignes du
unité).

?M :cpp def
Définit le mappage cpp magique à introduire dans confmagic.h chaque fois que le concerné
symbole est utilisé. Il y a un implicite '?sym'gardant où sym est le nom du symbole
défini par la ligne de tête ?M:.

?M:. Ferme le confmagic.h demande d'inscription.

?W :coquille symbole liste:C symbole liste
Lie le destin des symboles coquillages à celui des symboles C : si l'un des C
symboles répertoriés est recherché, alors tous les symboles du shell sont marqués comme souhaités. Utile pour
force l'inclusion d'une unité (liste de symboles shell définie sur '%<') lorsque la présence de certains C
symbole est détecté. La liste des symboles du coquillage peut être laissée vide, pour profiter du côté
effet de l'emplacement du symbole C dans le préprocesseur intégré (le symbole étant défini
pour ce préprocesseur s'il est situé dans la source). Chercher des motifs avec un espace
en eux, vous devez citer les symboles C entre guillemets simples, comme dans 'struct
fuseau horaire'.

?V :en lecture seule symboles:lire écrire symboles
Il s'agit d'un métalint indice et ne doit être utilisé que dans des unités spéciales exportant du shell
variables. Les variables avant le milieu ':' sont exportées en lecture seule (en les modifiant
émettra un avertissement), tandis que d'autres symboles peuvent être librement lus et modifiés.

?F:fichiers créée
Cette ligne a deux objectifs : c'est un métalint indice, et aussi un espace réservé pour
avenir je fais utilisation. Il doit lister trois types de fichiers : les fichiers temporaires qui sont
créés pour un test, les UU privés créés dans le répertoire UU pour plus tard
lecture, et les publics laissés dans le répertoire racine du paquet. Temporaire
les fichiers doivent être listés avec un '!' caractère (ce qui signifie « non ! ils ne sont pas réutilisés
plus tard !"), les fichiers UU privés doivent être précédés d'un './' (ce qui signifie : pour les utiliser, disons
./déposer, pas seulement filet), et les publics doivent être nommés tels quels.

?T :coquille temporaires
Une autre métalint indice. Cette ligne liste toutes les variables shell utilisées comme temporaires
dans la section de coque de cette unité.

?RÉ:symbole='Plus-value'
Valeur d'initialisation pour les symboles utilisés comme dépendances conditionnelles. Si non ?D: la ligne est
trouvé, une valeur nulle est utilisée à la place. Les métalint programme vous avertira si un
symbole est utilisé au moins une fois en tant que dépendance conditionnelle et n'a pas de
?D : initialisation. C'est une bonne pratique d'ajouter ces lignes même pour un null
initialisation car elle met l'accent sur le caractère éventuellement optionnel d'un symbole.

?O :tous message you souhaitez
Cette directive indique que cette unité est obsolète dans son ensemble. Chaque fois que l'utilisation d'un
de ses symboles est fait (ou utilisation indirecte via des dépendances), le message est émis sur
l'écran (sur stderr). Vous pouvez mettre une ou plusieurs lignes, auquel cas chaque ligne sera
être imprimé, dans l'ordre.

?PELUCHE:métalint indices
Voir le métalint page de manuel pour une explication des astuces distinctes qui peuvent être
utilisé.

?INIT :initialisation code
Le code d'initialisation spécifié par cette ligne sera chargé en haut de la
Configurer script à condition que l'unité soit nécessaire.

C Symbole Aliasing
Parfois, il n'est pas possible de s'appuyer sur métaconfigla propre sélection par défaut de config_h.SH
commentaires et définition du symbole C. C'est là que l'aliasing entre en jeu. Comme c'est plutôt
difficile à expliquer, nous étudierons un exemple pour comprendre le mécanisme sous-jacent.

L'unité d_const.U essaie de déterminer si votre compilateur C connaît ou non le const
mot-clé. Si ce n'est pas le cas, nous voulons remapper ce mot-clé sur une chaîne nulle, afin de laisser le
compilation du programme. De plus, nous souhaitons déclencher automatiquement le test lorsque le const mot
est utilisé.

Voici les parties pertinentes de l'unité d_const.U :

?MAKE:d_const: cat cc ccflags Setvar
?MAKE : -pick ajouter $@ %
?S:d_const :
?S : Cette variable définit conditionnellement le symbole HACONST, qui
?S : indique au programme C que ce compilateur C connaît le
?S : type const.
?S :.
?C:HASCONST ~ %< :
?C : Ce symbole, s'il est défini, indique que ce compilateur C connaît
?C : le type const. Il n'est pas nécessaire de tester réellement ce symbole
?C : au sein de vos programmes. La simple utilisation du mot-clé "const"
?C : déclencher les tests nécessaires.
?C:.
?H:?%<:#$d_const HACONST /**/
?H:?%<:#ifndef HACONST
?H:?%<:#define const
?H:?%<:#endif
?H :.
?W:%<:const
?LINT:définir d_const
?LINT:const connu
: vérifier le mot-clé const
écho " "
echo 'Vérification pour voir si votre compilateur C connaît "const"...' >&4
/bin/chat >const.c <<'EOCP'
principale()
{
caractère const *foo ;
}
EOCP
if $cc -c $ccflags const.c >/dev/null 2>&1 ; alors
val="$définir"
echo "Ouais, c'est le cas."
d'autre
val="$undef"
echo "Non, ce n'est pas le cas."
fi
définir d_const
évaluer $setvar

Nous remarquons d'abord l'utilisation d'une ligne ?W:, qui dit en gros : "Cette unité est recherchée lorsque le
const le mot-clé est utilisé dans un fichier C.". Afin de remapper conditionnellement const à un nul
chaîne dans config.h, j'ai choisi de définir conditionnellement HACONST via $d_const.

Cependant, cela pose un problème, car le HACONST le symbole ne sera pas utilisé dans le
sources, seuls les const jeton est. Et le ?H : ligne définissant HACONST est implicitement
gardé par ' ?HASCONST'. Par conséquent, nous devons ajouter la contrainte explicite '?%<' pour dire
métaconfig que ces lignes devraient être incluses dans config_h.SH chaque fois que le symbole '%<'
est recherché (%< fait référence au nom de l'unité, ici d_const).

C'est presque parfait, car la ligne ?W: voudra d_const chaque fois que const est utilisé, alors
les lignes ?H: seront incluses dans le config_h.SH déposer. Cependant, le commentaire principal (?C:
lignes) attaché à HACONST est lui-même également gardé via HACONST, c'est-à-dire qu'il a un implicite
Contrainte '?HASCONST'. D'où la nécessité de aliasing le HACONST symbole à '%<'.

La partie restante de l'unité (la partie coque) est vraiment simple. C'est simplement
essaie de compiler un exemple de programme C en utilisant le const mot-clé. Si c'est possible, alors ce sera
Vous permet de définir $d_const via le $setvar fonction (définie par le Setvar.U unité). Voir le paragraphe
sur les unités spéciales pour plus de détails.

Marque Commandes
Sur la ligne de commande ?MAKE:, vous pouvez écrire une commande shell à exécuter telle quelle ou une
spécial -choisir commande qui est piégé par métaconfig et analysé pour voir ce qui devrait être
terminé. Le "-" de début n'est là que pour empêcher faire d'échouer lorsque la commande revient
un statut différent de zéro -- ce n'est pas vraiment nécessaire puisque nous utilisons 'faire -n' pour résoudre le
dépendances, mais je vous conseille de le conserver au cas où il deviendrait obligatoire dans les futures versions.
La syntaxe du en particulier pendant la préparation la commande est:

-choisir cmd $@ fichier cible

De $@ est la macro standard dans les Makefiles représentant la cible actuelle (le nom
de l'unité en cours de construction, avec l'extension finale .U dépouillé). Les cmd la partie est la
présenter métaconfig commande à exécuter, et le fichier cible est encore un autre paramètre, dont
l'interprétation dépend de la cmd lui-même. Il a également son extension finale .U dépouillé et
fait normalement référence à un fichier d'unité, à moins qu'il ne commence par './' auquel cas il en référence un
des métaconfig fichiers de contrôle dans le '.MT répertoire.

Les commandes disponibles sont :

add Ajoute le fichier cible à Configurer.

ajouter.Config_sh
Remplit cette partie de Configurer produire le config.sh déposer. Seulement utilisé
les variables sont ajoutées, les conditionnelles (des dépendances conditionnelles) sont
sauté.

add.Null Ajoute la section initialisant toutes les variables shell utilisées à une chaîne vide.

c_h_weed Produit le config_h.SH déposer. Seules les lignes nécessaires sont imprimées.

cm_h_weed Produit le confmagic.h déposer. Seules les lignes nécessaires sont imprimées. Cette
la commande n'est activée que lorsque le -M commutateur est donné, ou lorsqu'un confmagic.h filet
existe déjà.

fermer.Config_sh
Ajoute le symbole 'EOT' final sur une ligne à part pour terminer le document ici
construire produisant le config.sh fichier.

prepend Ajoute le contenu de la cible au début fichier cible si ce fichier n'est pas vide.

mauvaise herbe Ajoute l'unité à Configurer comme le ajouter commande, mais faites quelques tests supplémentaires
pour supprimer le '?symbole' et '%symbole' lignes de la fichier cible si le symbole
n'est pas voulu ou voulu sous condition. La forme '%' n'est utilisée qu'en interne par
métaconfig tout en produisant ses propres fichiers .U dans le '.MT'répertoire.

essuyer Identique à ajouter vraiment, mais effectue une substitution de macro supplémentaire. Les
les macros disponibles sont décrites dans le Câblé Macros paragraphe.

En remarque, métaconfig génère un -cond commande en interne pour traiter les conditions
dépendances. Vous ne devez pas l'utiliser vous-même, mais vous le verrez si vous scannez le
généré Makefile dans l' .MT répertoire.

Câblé Macros
Les macros suivantes sont reconnues par le Essuyer commande et substitué avant l'inclusion dans
Configurer:

Le numéro de révision de base du package, dérivé de .paquet.

La date du jour.


L'adresse e-mail du mainteneur de ce paquet, dérivée de votre
.paquet.


Le nom du package, tel qu'il est dérivé de votre .paquet fichier.


Le niveau de patch du métaconfig programme (déconseillé au profit de ).


Le niveau de révision SVN du métaconfig .

Le numéro de version du métaconfig .

Ces macros sont principalement utilisées pour identifier les métaconfig version qui a généré un
particulier Configurer script et pour quel package cela a été fait. L'adresse e-mail du
mainteneur est câblé dans les principales instructions qui Configurer s'imprime au démarrage.

Articles de métaconfig les versions comprennent une syntaxe beaucoup plus générale de la forme :

<$variable>

qui est remplacé au moment de la génération de Configure par la valeur de variable tiré de votre
.paquet déposer. Finalement, l'ancien format de macro câblé disparaîtra et <$baserev>
remplacera dans toutes les unités fournies.

# Unités
Les unités spéciales suivantes sont utilisées pour factoriser le code et fournir un niveau supérieur
fonctionnalités. Ils produisent soit un script shell qui peut être sourcé, soit un shell
variable qui peut être eval'ed. Le passage des paramètres se fait via des variables connues, soit
nommé ou anonyme comme $1, $2, etc... (qui peut être facilement défini via le shell set
opérateur). Lorsque Configurer exécute, il crée et entre dans un UU répertoire, donc chaque
le script produit se trouve là-dedans et n'interfère pas avec les fichiers de votre package.

Voici les unités spéciales que vous devez connaître et la façon de les utiliser.

Cppsym.U
Cette unité produit un script shell appelé Cppsym, qui peut être utilisé pour déterminer
si un symbole dans une liste est défini par le préprocesseur C ou le compilateur C que vous avez
spécifié. Il peut déterminer le statut de n'importe quel symbole, bien que les symboles dans
(liste d'attributs) sont plus faciles à déterminer.

Csym.U
Ceci définit la variable shell $csym, utilisée en interne par Configurer pour vérifier si un
le symbole C donné est défini ou non. Une utilisation typique est :

définir le résultat du symbole [-fva] [précédent]
évaluer $csym

Cela définira le résultat variable à 'true' si la fonction [-f], variable [-v] ou
array [-a] est défini, 'false' sinon. Si une valeur précédente est donnée et que le -r
commutateur a été fourni à Configurer (voir le Configurer Options paragraphe), alors que
valeur est réutilisée sans remise en question.

La façon dont ce calcul est effectué dépend de la réponse que l'utilisateur donne à la question
Configurer demandera si elle doit effectuer une nm extraction ou non. Si la
l'extraction a été effectuée, l'appareil parcourt simplement la liste des symboles, sinon
il effectue un test de lien de compilation, à moins que -r a été donné pour réutiliser le précédemment calculé
valeur, naturellement...

Fin.U
En copiant cet appareil dans votre U répertoire et ajout de dépendances sur le
?MAKE : ligne, vous pouvez forcer une unité donnée à être chargée dans Configurer même si ce n'est pas
autrement voulu. Certaines unités ne peuvent être forcées Configurer de cette façon.

Filex.U
Cette unité produit un script shell exp_fichier qui développera les noms de fichiers commençant par
tildes. Une utilisation typique est :

exp_name=`./fileexp $name`

pour attribuer le nom de fichier étendu dans nom_exp.

Findhdr.U
Cette unité produit un trouverhdr script qui est utilisé pour localiser les fichiers d'en-tête dans
$usrinc ou d'autres endroits inconnus utilisant les capacités cpp. Le script reçoit un
inclure le nom de base du fichier comme 'stdio.h' ou 'sys/file.h' et il renvoie le chemin complet de
le fichier inlcude et un statut zéro s'il est trouvé, ou une chaîne vide et un statut différent de zéro
si le fichier n'a pas pu être localisé.

Obtenirfile.U
Cette unité produit un peu de code shell qui doit être sourcé afin d'obtenir un fichier
nom et faire quelques contrôles de santé mentale. Facultativement, une extension de ~name est effectuée.

Pour utiliser cet appareil, $rp ainsi que $dflt doit contenir la question et la réponse par défaut, qui
sera transmis tel quel au ma lecture scénario (voir à venir Ma lecture.U). La $fn
variable contrôle l'opération et le résultat est renvoyé dans $ans.

Pour localiser un fichier ou un répertoire, mettez 'f' ou 'd' dans f~/. Si un '~' apparaît, alors ~nom
le remplacement est autorisé. Si un '/' apparaît, seuls les chemins absolus sont acceptés et
~Les substitutions de noms sont toujours développées avant de revenir. Si '+' est spécifié,
les contrôles d'existence sont ignorés. Si 'n' apparaît dans $fn, alors l'utilisateur est autorisé à
répondez 'aucun'.

Habituellement, à moins que vous n'ayez demandé la portabilité, la substitution de ~nom se produit lorsque cela est demandé.
Cependant, il arrive parfois que vous souhaitiez contourner la portabilité et forcer le
substitution. Vous pouvez utiliser la lettre 'e' (développer) pour le faire.

Si le type spécial 'l' (localiser) est utilisé, alors le $fn la variable doit se terminer par un ':',
suivi d'un nom de base de fichier. Si la réponse est un répertoire, le nom de base du fichier sera
ajouté avant de tester l'existence du fichier. Ceci est utile dans les questions de style localisation
comme ça:

dflt='~nouvelles/lib'
: pas besoin de spécifier 'd' ou 'f' lorsque 'l' est utilisé
fn='l~:actif'
rp='Où est le fichier actif ?'
. ./getfile
actif="$ans"

De plus, la lettre « p » (chemin) peut être utilisée en conjonction avec « l » pour indiquer
obtenir un fichier qu'une réponse sans '/' doit être acceptée, en supposant qu'elle
être dans le PATH de tout le monde au moment où cette valeur sera nécessaire.

La possibilité de spécifier une liste de réponses qui doivent être acceptées est également utile.
mot pour mot, en contournant toutes les vérifications. Cette liste doit être entre parenthèses et les éléments
doivent être séparés par des virgules, sans espaces entrelacés. N'oubliez pas de citer le
chaîne résultante puisque les parenthèses sont significatives pour le shell. Par exemple:

dflt='/bin/install'
fn='/fe~(installer,./installer)'
rp='Utiliser quel programme d'installation ?'
. ./getfile
install="$ans"

permettrait à l'utilisateur de spécifier uniquement des chemins complets faisant référence à des fichiers existants,
mais autorisez toujours les réponses spéciales "install" et "./install" telles quelles (en supposant que
bien sûr, quelque chose les traitera spécialement plus tard dans la chaîne, car ils le font
non conforme au cadre général attendu).

Si la réponse à la question est « aucun », alors les contrôles d'existence sont ignorés et
la chaîne vide est renvoyée. A noter que depuis obtenir un fichier en cours ma lecture en interne, tout
les fonctionnalités disponibles avec ma lecture appliquer ici à.

Si une valeur complètement étendue est nécessaire (par exemple dans un Makefile), vous pouvez utiliser
le $ansexp variable qui est toujours configurée correctement par obtenir un fichier au fur et à mesure de l'expansion
version de $ans. Bien sûr, il ne développera pas ~name si vous ne l'avez pas autorisé dans le
première place dans le $fn variable.

Inhdr.U
Cette unité produit le $inhdr variable shell, utilisée en interne par Configurer vérifier
si un ensemble d'en-têtes existe ou non. Une utilisation typique est :

définir l'en-tête i_header [ en-tête2 i_header2 ... ]
évaluer $inhdr

Cela imprimera un message indiquant si l'en-tête a été trouvé ou non et définira le
i_header variable en conséquence. Si plusieurs en-têtes sont spécifiés et que le premier
l'en-tête n'est pas trouvé, nous essayons le suivant, jusqu'à ce que la liste soit vide ou que l'on en trouve un.

Inlibc.U
Cette unité produit le $inlibc variable shell, utilisée en interne par Configurer vérifier
si une fonction C donnée est définie ou non. Une utilisation typique est :

définir la fonction d_func
évaluer $inlibc

Cela imprimera un message, indiquant si la fonction a été trouvée ou non et définie
$d_fonc par conséquent. En interne, il a utilisé le $csym routine.

Loc.U
Cette unité importante produit un script shell loc qui peut être utilisé pour savoir où
dans une liste de répertoires se trouve un fichier donné. Le premier argument spécifie le fichier à
être localisé, le deuxième argument est ce qui sera renvoyé si la recherche échoue, et le
Les arguments restants sont une liste de répertoires dans lesquels le fichier doit être recherché. Pour
exemple:

dflt=`./loc sendmail.cf X / usr / lib /var/lib/sendmail / lib`

mettrait en place $dflt à X sinon envoyermail.cf fichier a été trouvé dans les répertoires répertoriés,
ou quelque chose comme /usr/lib/sendmail.cf sur certains systèmes. Voir également Obtenirfile.U.

MailAuteur.U
Cette unité doit être incluse sur la ligne ?MAKE: de votre propre End.U privé pour faire
dans Configurer. Il propose à l'utilisateur de s'inscrire auprès de l'auteur, éventuellement
être averti lorsque de nouveaux correctifs arrivent ou les recevoir automatiquement lorsqu'ils sont émis.
Vous devez installer agent de messagerie pour ce faire (au moins la version 3.0).

MailList.U
Cette unité doit être incluse sur la ligne ?MAKE: de votre propre End.U privé pour faire
dans Configurer. Il propose à l'utilisateur de s'inscrire ou de se désinscrire à une liste de diffusion
où se déroulent les discussions relatives au paquet. Tu dois courir emballer
et répondez aux questions liées à la liste de diffusion pour configurer les variables appropriées dans votre
.paquet avant que cet appareil ne devienne opérationnel.

Moninit.U
Copiez cette unité dans votre privé U répertoire pour ajouter vos propres valeurs par défaut à certains
variables internes. Cette unité est chargée dans Configurer après tout le défaut
les initialisations ont été faites.

Ma lecture.U
Cette unité produit le ma lecture script shell qui doit être sourcé pour faire un
lire. Il permet les échappements de shell, l'affectation par défaut et l'évaluation des paramètres, comme
documenté dans l'unité Instruct.U. Il permet également un réglage dynamique de la -d option,
qui sera utilisé pour le reste de l'exécution du script.

Pour utiliser cet appareil, $rp doit tenir la question et $dflt devrait contenir la valeur par défaut
réponse. La question sera imprimée par le script lui-même, et le résultat est renvoyé
dans l' $ans variable.

Voici une utilisation typique :

dflt='y'
rp='Question ?'
. ./ma lecture
value="$ans"

Voir l'unité elle-même pour plus d'informations.

Ancienconfig.U
Cette unité doit faire partie de votre dépendance ?MAKE: ligne lorsque certaines de vos unités essaient
pour réutiliser une ancienne valeur de symbole. Cette unité est chargée d'obtenir les anciennes réponses
de config.sh ou en fournissant des conseils utiles lors de l'exécution sur une plate-forme donnée pour le
première fois. Voir le Configurer Allusions paragraphe pour plus d'informations sur les astuces.

Préfixe.U
Le but de cette unité est de détecter les changements dans le répertoire de préfixe d'installation pour
recalculer automatiquement les valeurs par défaut appropriées à partir des réponses précédentes. Il s'appuie sur le
valeur de la $ancienpréfixe variable qui contient le répertoire de préfixe précédent lorsqu'il
changé, et est vide sinon. Par exemple, si le préfixe a été modifié de /opter à
/ Usr / local, alors le répertoire d'installation binaire précédent sera modifié de
/opter/bin à / usr / local / bin, ou restera inchangé s'il était, disons, / bin.

Vous devez appeler set avant de délivrer un eval on $préfixe, Tels que:

définir dflt var [répertoire]
eval $préfixe

qui mettrait $dflt à $var or $préfixe/répertoire selon que le préfixe est resté
le même ou pas. Si dir est la chaîne aucun, une valeur d'espace unique dans $dflt est conservé comme-
est, même lorsque le préfixe change. Si dir est omis, alors $dflt est défini sur un vide
chaîne si le préfixe a changé, en $var autrement.

Préfixe.U
L'intention de cette unité est similaire à celle de Prefixit.U, c'est-à-dire qu'elle aide à fixer le
chaîne par défaut pour s'adapter aux changements de préfixe. Cependant, la variable shell $préfixeup,
lorsqu'il est évalué, ne restaurera que les extensions de nom de ~, le préfixe devrait utiliser un tel échappement
mécanisme. Utilisez-le comme :

définir dflt
évaluer $préfixeup

avant de demander via obtenir un fichier par exemple. Si le préfixe n'utilise pas ~name
expansion, alors ce qui précède sera une non-opération sur le y variable, naturellement.

Typedef.U
Cette unité produit le $typedef variable shell, utilisée en interne par Configurer vérifier
si un typedef existe ou non. Une utilisation typique est :

set typedef val_t default [inclut]
évaluer $typedef

Cela définira la variable val_t à la valeur de défaut si le typedef n'a pas été trouvé
parmi les fichiers d'inclusion répertoriés, ou pour typedef si trouvé. Si aucun fichier d'inclusion n'est
spécifié, l'appareil regarde dans seul. Si vous spécifiez des inclusions, seulement
ceux-ci sont examinés.

Unix.U
Le but de cette unité est de définir certains des ismes UNIX les plus courants via des variables
qui peut être modifié à partir de la ligne de commande ou via des fichiers d'indices appropriés. En particulier,
$_exe, $_o ainsi que $_a sont fixés. Toutes les unités doivent se référer à $_o et non à .o directement.
Les '.' fait partie de ces variables.

Setvar.U
Cette unité produit la variable, qui est utilisée en interne par Configurer pour définir un
Vous permet de définir/undef valeur à un symbole donné, émettant un avertissement lorsqu'il change soudainement
à partir d'une valeur précédente. Par exemple:

val="$définir"
définir d_variable
évaluer $setvar

Si le précédent $d_variable valeur était non nulle et val $ est différent, un "whoa"
un avertissement est émis.

Whoa.U
Cette unité produit le whoa script, qui émet un avertissement lorsque le Plus-value en variable
dont le nom est $var n'est pas la même que son ancienne valeur précédente détenue dans $ était. Sur
revenir, $td ainsi que $ tu détenir la valeur appropriée pour Vous permet de définir or indéfini la variable. Voir
exemples dans Inlibc.U.

Intégré Pré-processeur
Chaque unité à inclure dans Configurer est exécuté via un préprocesseur intégré. Pré-
les instructions du processeur sont introduites par le caractère '@' ('#' est le commentaire du shell
personnage). Il fonctionne simplement comme le fait le préprocesseur C mais permet le shell et le perl
s'échappe. Voici les fonctions disponibles :

@si expression
If expression est vrai, continuez à charger le code jusqu'à @end, @elsif ou @else.

@elsif expression
Choix alternatif. Si expression est vrai, continuez à charger le code jusqu'à @end,
un autre @elsif ou @else.

@else Code par défaut à charger si le @if expression était faux et aucun des
facultatif @elsif correspond. Charger jusqu'à @end.

@end Ferme l'instruction de chargement conditionnel ouverte par @if.

@définir symbole
Indique au préprocesseur que symbole est désormais défini.

Le conditionnel expression peut inclure des noms de symboles (la valeur est vraie si le symbole est souhaité ou
défini par @définir ou des échappements shell/perl. Ces atomes peuvent être combinés en utilisant le
opérateurs booléens traditionnels '!' pour la négation, '&&' pour le and logique, et '||' pour logique
ou.

Le texte entre crochets simples est un test shell, tandis que le texte entre crochets doubles est
un test perl. A savoir les expressions :

{ coquille texte }
{{ perl texte }}

sont traduits en :

if coquille texte >/dev/null 2>&1; puis sortie 0 ; sinon sortie 1; Fi
si (perl texte) {sortie 0;} else {sortie 1;}

et l'état de sortie est utilisé de manière standard pour obtenir une valeur booléenne, c'est-à-dire que 0 est vrai et
tout le reste est faux. Notez que seules des conditions simples peuvent être exprimées en perl, jusqu'à ce que
du code complexe peut être chargé dans métaconfig et exécuté.

Le préprocesseur intégré peut être utilisé pour régler finement certaines unités (voir d_gethname.U pour
exemple complexe) selon les symboles effectivement utilisés par le programme ou les fichiers
présent dans la distribution. Par exemple, le Ancienconfig.U utilise un test comme :

@if {test -d ../indices}

ainsi que Configurer contiendra un code dépendant de l'indice uniquement s'il existe un indices répertoire dans le
répertoire de niveau supérieur du package. Notez que les tests sont exécutés à partir du '.MT'répertoire,
d'où le « ../ » nécessaire dans le test.

Le pré-processeur peut également être utilisé pour éviter de mettre du code inutile lorsqu'un symbole n'est pas
défini. Les unités définissant plus d'un symbole peuvent être protégées de cette façon (puisque l'unité est
chargé dans son ensemble) en rassemblant le code dépendant du symbole dans une paire @if/@end. Pour
exemple:

@si I_TIME || I_SYS_TIME || I_SYS_TIME_KERNEL
need_time_h='true'
@autre
need_time_h='false'
@finir

testera si le code source utilise l'un des trois symboles qui contrôlent
le heure.h or sys/heure.h inclusion et définissez le symbole de la coquille en conséquence. Ça donne
Configurer un retour sur ce dont les sources ont besoin et éviter l'inconvénient d'avoir fixé
unités congelées.

Via les lignes '?W:', vous pouvez obtenir des combinaisons intéressantes. Par exemple, le i_time.U unité
doit savoir si les sources C utilisent struct fuseau horaire taper. Par conséquent,
la ligne:

?W::fuseau horaire

est utilisé pour son effet secondaire de définition du symbole fuseau horaire pour le préprocesseur. Les
le code de l'unité peut alors dire :

@if fuseau horaire
pour s_timezone dans '-DS_TIMEZONE' '' ; faire
@autre
s_timezone=''
@finir

... code utilisant s_timezone ...

@if fuseau horaire
fait
@finir

et avoir une boucle supplémentaire en essayant deux valeurs successives pour le s_fuseau horaire variable, mais seulement
si besoin.

Obsolète Symboles
Les symboles obsolètes sont conservés pour faciliter la transition avec les anciens métaconfig unités. Sauf si
le -o le commutateur est passé à métaconfig ils seront ignorés. Cependant, un Obsolète fichier sera
être généré, vous indiquant quels fichiers utilisent ces symboles obsolètes et quels
sont les nouveaux symboles à utiliser.

La durée de vie des symboles obsolètes est d'une révision complète, c'est-à-dire qu'ils seront supprimés lorsque le
la prochaine révision de base est publiée (les mises à jour de correctifs ne comptent bien sûr pas). Il est donc
sage de traduire vos sources et de commencer à utiliser les nouveaux symboles dès que possible.

Configurer Allusions
Il peut arriver que la logique de configuration interne fasse les mauvais choix. Pour
exemple, sur une plate-forme, le vfork () l'appel système est présent mais interrompu, il devrait donc
pas être utilisé. Il n'est pas possible d'inclure ces connaissances dans les unités elles-mêmes, car
cela pourrait être un problème temporaire que le fournisseur finira par résoudre, ou quelque chose qui
a été introduit par une nouvelle mise à niveau du système d'exploitation.

Quoi qu'il en soit, pour tous ces petits problèmes trop spécifiques au système, métaconfig
fournit la prise en charge des fichiers d'indices. Pour l'utiliser, vous devez créer un indices répertoire dans le
répertoire de niveau supérieur du package et l'avoir lorsque vous exécutez métaconfig. Cela chargera le
partie liée à l'indice de Ancienconfig.U.

À partir de là, vous pouvez prédéfinir certaines des variables du shell Configurer utilise dans un système d'exploitation spécifique
fichier .sh. Il y a du code dans Ancienconfig.U qui essaie de deviner quels fichiers d'indices sont nécessaires par
calcul d'un nom standard basé sur le nom du système d'exploitation, le nom du noyau, la version
numéro, etc... Comme cette information est susceptible de changer rapidement, je ne la documente pas
ici. Vous devez désosser le code à partir de Ancienconfig.U.

Lorsque vous publiez votre package pour la première fois, votre répertoire de fichiers d'astuces doit être vide. Si la
les utilisateurs de votre forfait se plaignent d'avoir un problème avec Configurer par défaut sur un
système particulier, vous devez voir s'il s'agit d'un problème spécifique à la plate-forme ou d'un
un général. Dans le premier cas, il est temps d'introduire un nouveau fichier d'indices, tandis que dans le
dernier, l'unité correspondante devrait être révisée.

Par exemple, les systèmes SGI sont connus pour avoir un vfork () appel système, à partir de ce
l'écriture. Et le nom du fichier d'indice correspondant est sgi.sh. Donc tout ce que vous avez à faire est de créer
a astuces/sgi.sh fichier dans lequel vous écrivez :

d_vfork="$define"

qui remappera toujours fourche on fourche (voir d_vfork.U). Lors de l'exécution sur des systèmes SGI pour le
première fois, Configurer détectera qu'il y a un astuces/sgi.sh dossier, et que nous sommes sur
une machine IRIX (le nom du noyau est souvent /irix), il proposera donc sgi en tant que
indice possible. Si l'utilisateur l'accepte, et puisque le $d_vfork la valeur est modifiée via le
$setvar appel, un waouh ! sera émis pour avertir que nous sommes sur le point de remplacer la valeur
calculé par Configurer.

Notez que vous n'avez pas à fournir TOUTE les indices connus par Ancienconfig.U. Si un fichier d'indices est
manquant, il ne sera pas proposé comme choix possible. Les tests heuristiques ont été exécutés pour calculer
les candidats indice possibles sont floconneux. Si vous avez de nouvelles valeurs ou des tests différents, veuillez
envoie-les moi...

Primordial Choix
Si vous créez un config.sur fichier dans le répertoire de niveau supérieur, Configurer vous demandera si vous
souhaitez le charger pour remplacer les valeurs par défaut. Ceci est fait avant la création du
config.sh fichier, il vous donne donc une chance de corriger les valeurs qui y sont stockées.

Ceci est distinct de l'approche des astuces en ce qu'il s'agit d'un fichier local, que l'utilisateur est
libre de créer pour son propre usage. Vous ne devez pas fournir un tel fichier vous-même, mais laissez le
l'utilisateur connaît cette possibilité.

Configurer Options
La Configurer le script peut être appelé avec certaines options spécifiées sur la ligne de commande, pour
modifier légèrement son comportement. Voici les options autorisées :

-d Utilisez les valeurs par défaut pour toutes les réponses.

-e Continuer sans remettre en cause la production de config.sh.

-f filet Utilisez le fichier spécifié comme configuration par défaut. Si ce commutateur n'est pas utilisé,
la configuration est tirée de config.sh, lorsqu'il est présent.

-h Imprimer le message d'aide et quitter.

-r Réutilisez la valeur des symboles C si possible. Cela évitera le coûteux nm symbole
extraction. Si utilisé la première fois (sans fichier de configuration précédent),
Configurer va essayer de compiler et de lier un petit programme afin de connaître
la présence ou l'absence d'un symbole.

-s Mode silencieux. Seules les chaînes imprimées sur le descripteur de fichier #4 seront visibles sur le
écran (ce sont les messages importants). Il n'est pas possible d'éteindre complètement
n'importe quelle sortie, mais vous pouvez utiliser 'Configurer -ders > / dev / null 2> et 1' avoir un plein
exécution par lots sans sortie et sans interaction de l'utilisateur requise.

-D symbole=valeur
Prédéfinit symbole supporter le spécifié Plus-value. Il est également possible d'utiliser '-D
symbole' qui utilisera une valeur par défaut de 'define'.

-E Arrêtez-vous à la fin des questions de configuration, après avoir produit un
config.sh. Cela n'effectuera aucun 'faire dépendre' ou extraction de fichiers .SH.

-K Utilisateur averti. Lorsque vous utilisez cette option, vous savez ce que vous faites et
Par conséquent, la config.sh fichier sera toujours traité comme s'il était destiné à être
réutilisé, même s'il a pu être généré sur un système extraterrestre. Ça aussi
empêche l'abandon lorsque Configurer détecte un compilateur C inutilisable ou un mauvais jeu
des drapeaux C. D'autres raccourcis peuvent également être activés par cette option dans le
futur. Cette option est documentée dans le Configurer message d'utilisation, pour nous rappeler
sur son existence, mais on espère que la description donnée sera assez cryptique.
:-)

-O Autoriser les valeurs spécifiées via un -D or -U pour remplacer les paramètres de tout chargé
fichier de configuration. Ce n'est pas le comportement par défaut puisque le remplacement
ne pas être propagé aux variables dérivées de celles que vous modifiez actuellement.
Naturellement, sans -O, le paramétrage n'est effectué que lorsqu'aucun fichier de configuration n'est
chargé, ce qui est sûr puisque les variables dérivées n'ont pas encore été calculées...

-S Effectuez une substitution de variable sur tous les fichiers .SH. Vous pouvez le combiner avec le
-f commutateur pour propager n'importe quelle configuration que vous aimez.

-U symbole =
Préconfigurations symbole porter une valeur vide. Il est également possible d'utiliser '-U symbole'
qui définira symbole à « undef ».

-V Imprimer le numéro de version du métaconfig qui a généré ce Configurer scénario
et sortie.

Fonctionnement Environment
Au démarrage, Configurer crée un local UU répertoire et s'exécute à partir de là. Le répertoire
est supprimé lorsque Configure se termine, mais cela signifie que vous devez exécuter le script à partir d'un endroit où
vous pouvez écrire, c'est-à-dire pas à partir d'un système de fichiers en lecture seule.

Tu peux courir Configurer à distance cependant, comme dans :

../paquet/Configurer

pour configurer des sources qui ne sont pas présentes localement. Tous les fichiers générés seront mis dans
le répertoire à partir duquel vous exécutez le script. Cette magie se fait grâce à la src.U
unité, qui définit le $src ainsi que $rsrc variables pour pointer vers les sources du package. Cette
chemin est complet ou relatif, selon que Configurer a été invoqué via un formulaire complet ou
chemin relatif.

De l'intérieur UU sous-répertoire, vous pouvez utiliser $rsrc pour accéder aux fichiers sources (unités
faisant référence aux fichiers source, les indices de lien doivent toujours utiliser ce mécanisme et ne pas supposer que
fichier est présent dans le répertoire parent). Tous les Makefiles doivent utiliser la variable $src
comme pointeur vers les sources depuis le haut du répertoire de construction (où Configurer est exécuté),
soit directement, soit via un paramètre VPATH.

En cours d'exécution Configurer à distance, les fichiers .SH sont extraits dans le répertoire de construction, pas
dans l'arborescence des sources. Cependant, cela nécessite une sorte de faire support pour pouvoir compiler
les choses dans un répertoire de construction tandis que les sources se trouvent ailleurs.

En utilisant la magie Redéfinitions
En utilisant le -M commutateur, certains remappages magiques peuvent avoir lieu dans un confmagic.h
déposer. Ce fichier doit être inclus après config.h, bien sûr, mais aussi après tout le
d'autres fichiers d'inclusion nécessaires. À savoir:

#include "config.h"

autre inclusions

#include "confmagic.h"

Typiquement, confmagic.h tentera de remapper bcopie() on memcpy() sinon bcopie() is
disponible localement, ou transformer fourche développement fourche lorsque cela est nécessaire, rendant ainsi inutile
se soucier de la HAS_VFORK symbole.

Cette magie de configuration est documentée dans le fichier Glossaire.

Unité Gabarits
Il existe un ensemble de modèles d'unités dans le métaconfig répertoire source, qui sont destinés à
être utilisé par un programme (pas encore écrit) pour produire rapidement de nouvelles unités pour divers types de
situations. Pas de documentation pour ce projet inachevé, mais j'ai pensé le mentionner
dans la page de manuel au cas où vous souhaiteriez le faire vous-même et ensuite y contribuer...

AUTEURS


Larry Mur[email protected]> pour la version 2.0.
Harlan Stenn[email protected]> pour les extensions d'unités importantes.
Raphaël Manfredi[email protected]>.
De nombreux autres contributeurs de la métaconfig unités. Voir le dossier de crédit pour une liste.

Utiliser metaconfig en ligne à l'aide des services onworks.net


Serveurs et postes de travail gratuits

Télécharger des applications Windows et Linux

Commandes Linux

Ad