metaconfig - Online nel cloud

PROGRAMMA:

NOME

metaconfig - un generatore di script di configurazione

SINOSSI

metaconfig [-dhkmostvwGMV ] [-L dir ]

DESCRIZIONE

Metaconfigurazione è un programma che genera script di configurazione. Se non sai cosa a
Lo script di configurazione è, per favore vai al TUTORIAL sezione di questa pagina di manuale. Se vuoi
una descrizione completa (formale) del modo di usare metaconfig e le sue unità, si prega di guardare il
RIFERIMENTO sezione. Quella che segue è una rapida introduzione e riferimento per gli esperti
utenti.

Metaconfigurazione opera da un insieme di unità che definiscono tutto ciò che conosce metaconfig
portabilità. Ogni unità è autonoma e non deve essere registrata da nessuna parte
diverso dall'inclusione nella directory U pubblica o nella directory U privata. Se
il pacchetto dist (di cui metaconfig fa parte) è installato in LIB, quindi il public U
la directory è LIB/dist/mcon/U. Su questa macchina, la directory LIB è /usr/share/dist. Tuo
la directory U privata, se ne hai una, si trova nella directory di livello superiore del tuo pacchetto.
Prima che tu possa correre metaconfig devi fare diverse cose:

· Creare un file .package nella directory di primo livello del pacchetto eseguendo pacchetto.
Questo programma ti chiederà del tuo pacchetto e ricorderà cosa gli dici in modo che
tutti i programmi dist possono essere intelligenti.

· Consulta il Glossario (in LIB/dist/mcon) e scrivi i tuoi script di shell e programmi C
in termini di simboli che metaconfig sa definire. Non hai bisogno di dirlo
metaconfig quali simboli hai usato, dal momento che metaconfig lo capirà per te.

· Genera qualsiasi script .SH necessario per scrivere Makefile o script di shell che dipenderanno
sui valori definiti da Configura. C'è un programma chiamato fareSH questo ti aiuterà
convertire uno script semplice in un modello script.SH; alcune modifiche dovranno ancora essere
eseguita sul file .SH risultante per spostare la parte di configurazione della variabile nel
parte superiore dello script (vedi i commenti in linea generati da fareSH all'interno del tuo .SH
file).

· Creare un file MANIFEST.new nella directory di livello superiore che elenchi tutti i file in
il tuo pacco Questo file rimarrà privato e non farà parte della finale
distribuzione. (Per comodità, il file MANIFEST verrà utilizzato da metaconfig if
non c'è ancora nessun file MANIFEST.new.) Il nome del file dovrebbe essere il primo campo su ciascuno
linea. Dopo alcuni spazi bianchi puoi aggiungere un breve commento che descrive il tuo file. Solo
i file di origine dovrebbero essere elencati lì. Il file speciale patchlevel.h (che è
gestito e mantenuto dagli strumenti di patching -- vedi colpetto(1)) dovrebbe essere parte del
MANIFEST.new, ma può essere ignorato silenziosamente da alcuni strumenti. Come regola generale,
solo i file mantenuti da RCS dovrebbero essere elencati lì dentro, il patchlevel.h file essendo
un'eccezione importante.

· Facoltativamente, potresti voler creare un file MANIFEST, che sarà una versione esportata
del tuo MANIFEST.new. Quel file deve essere parte della release, cioè elencato in entrambi
il tuo MANIFEST.new e il MANIFEST stesso. Uno di metaconfig le unità lo sanno
file e forzerà Configure a eseguire un controllo di rilascio, garantendo tutti i file
elencati fanno parte della distribuzione. I file MANIFEST e MANIFEST.new dovrebbero
essere distinti, non collegamenti.

· Copia tutti i file .U che desideri modificare nella tua directory U privata. Qualsiasi file .U
nella tua directory U privata verrà utilizzata in preferenza rispetto a quella nella U public pubblica
directory. Ad esempio, un modo per forzare l'inclusione di qualsiasi unità è copiare End.U
file nella tua directory .U e aggiungi il nome dell'unità da cui vuoi dipendere
la fine della riga ?MAKE:. Alcune unità possono essere forzate SOLO in questo modo, vale a dire
quelli della forma Warn_*.U e Chk_*.U. Puoi anche personalizzare alcune impostazioni predefinite
Configura le variabili copiando Myinit.U nella directory U privata del tuo pacchetto e
impostando le variabili in quell'unità.

Ora sei pronto per correre metaconfig. Ciò creerà un Configurazione file, e facoltativamente a
config_h.SH file (se le tue fonti fanno uso di simboli C). I file generati saranno
essere automaticamente aggiunto al tuo MANIFEST.new se necessario. Non dimenticare di aggiornare il tuo
File MANIFEST però.

Per creare nuove unità, procedi come segue:

· Copiare un'unità simile in un nuovo file .U. Il nome che scegli dovrebbe essere il nome di a
variabile generata dall'unità, anche se questa è solo una comodità per te, non un
Requisiti. Dovrebbe essere di 12 o meno caratteri per evitare che il nome del file venga tagliato.
In realtà, dovrebbe essere 10 o meno, così chi vuole usare RCS può avere
a .U,v alla fine senza tagliare. Metaconfig usa il caso della prima lettera per
determina se una variabile è effettivamente prodotta da questa unità, quindi non capitalizzare il tuo
nome dell'unità se si suppone che produca una variabile di shell.

· Modifica il nuovo file .U per fare quello che vuoi. La prima riga ?MAKE: indica il
dipendenze; prima della lista finale due punti tutte le variabili che questa unità definisce, e
dopo i due punti finali tutte le variabili (o altre unità) da cui questa unità dipende.
È molto importante che questi elenchi siano accurati. Se una dipendenza è facoltativa e a
è possibile utilizzare il valore predefinito, è necessario anteporre la dipendenza con un segno '+'. Il
l'unità corrispondente non verrà caricata per calcolare il simbolo, a meno che non sia realmente richiesto
da un'altra unità.

· Per quanto possibile, parametrizza la tua unità in base alla variabile shell definita su
?INIT: linee. Questo sposterà le definizioni delle variabili fino all'unità Init.U, dove
possono essere sovrascritti dalle definizioni in Myinit.U, che è incluso dopo Init.U.

· Aggiungere la definizione di qualsiasi simbolo C desiderato come ?H: linee. Una riga che inizia con
?H:?%<: nel file .U verrà aggiunto all'eventuale file config.h se e solo se
metaconfig decide che questa unità è necessaria. Il %< sta per il nome dell'unità,
che sembra essere anche il nome del file (senza .U) se hai seguito il
convenzione. Metti sempre un commento su ogni riga ?H: nel caso in cui una delle variabili
le sostituzioni precedenti sulla riga iniziano un commento senza finirlo. Qualsiasi conchiglia
variabile che inizia con d_ potrebbe farlo, quindi fai attenzione. Se ometti il ​​?%<:, allora
metaconfig cercherà di intuire il simbolo la cui definizione è necessaria prima di qualsiasi
inclusione in config.h.

· Aggiungere definizioni di glossario come ?S: righe per variabili di shell e ?C: righe per C
variabili del preprocessore. Vedere un'unità corrente per esempi. È MOLTO importante
inizia ogni voce con un nome di simbolo giustificato a sinistra e termina ogni voce con una ?C:. o
?S:. linea. L'algoritmo che traduce le voci dei simboli del preprocessore C per
Il glossario nei commenti per config.h dipende da questo.

· Assicurati che l'ordine di tutti i tuoi ? le linee sono giuste. L'ordine corretto è:

?RCS: e ?X: fondamentalmente solo commenti
?MAKE: dipendenze metaconfig
?Y: direttiva layout unità
?S: definizioni della shell del glossario
?C: glossario C definizioni
?H: definizioni config.h
?M: definizioni confmagic.h
?W: simboli ricercati
?V: simboli visibili
?F: file creati da questa unità
?T: simboli di shell temporanei utilizzati
?D: valore predefinito delle dipendenze facoltative
?O: usato per contrassegnare le unità obsolete
?LINT: accenni di metalint
?INIT: inizializzazioni simboli shell

Ecco un esempio per mostrare l'ordinamento delle righe e i vari formati consentiti:

?RCS: $ID-RCS$
"RCS: Informazioni sul copyright"
?RCS: $RCS-Registro$
?X:
?X: Un esempio inventato
?X:
?FARE:d_uno due: tre +quattro Cinque
?MAKE: -pick add $@ %
?S: PREDEFINITO
?S:d_uno:
?S: Primo simbolo di shell, definisce condizionalmente UNO.
?S:.
?S:due:
?S: Secondo simbolo della conchiglia, valore per DUE.
?S:.
?CONO:
?C: Primo simbolo C.
?C:.
?C:DUE:
?C: secondo simbolo C.
?C:.
?H:#$d_one UNO /**/
?H:#definisce DUE "$due"
?H:#$d_uno UNO_DUE "$due"
?H:.
?M:capovolgi: HAS_FLIP
?M:#ifndef HAS_FLIP
?M:#definisci flip(x) flop(x)
?M:#endif
?M:.
?W:%<:uno_due
?V:p_uno p_due:p_tre
?F:file ./ftest !tmp
?T:tmp var
?D:due='undef'
?LINT:cambia tre
?INIT:two_init='2'
: segue il codice shell che implementa l'unità
p_one='uno'
p_two='due'
p_tre=""

Permettetemi di affermarlo ancora una volta: la definizione di unità di cui sopra è a falso uno per mostrare solo il
diverse possibilità. Un'unità del genere servirebbe comunque a ben poco... Qualcosa in più
le funzioni avanzate non sono descritte qui. Si prega di fare riferimento al RIFERIMENTO sezione per saperne di più
informazioni complete.

· Inserire l'unità nella directory U pubblica o privata a seconda dei casi.

· Riprova metaconfig.

· Invia la tua unità a [email protected] (Raffaello Manfredi) per l'inserimento nella copia master,
se pensi che sia di interesse generale.

Per aggiungere un nuovo programma da localizzare:

· Modificare Loc.U, e aggiungere il nome del programma sia alla riga ?MAKE: (tra le
due due punti) e a loclist o trylist (a seconda che il programma sia
obbligatorio o meno).

· Riesegui metaconfig.

· Inviami la tua unità per l'inclusione nella copia principale, se pensi che sia di carattere generale
interesse.

Note per la scrittura di file .U:

* Usa sempre "rm -f" perché ci sono sistemi in cui rm è interattivo per impostazione predefinita.

* Non usare "set -- ..." perché '--' non funziona con tutte le shell. Usa "imposta x ...;
cambio".

* Non utilizzare "unset ENV" poiché unset non è completamente portatile. Di' invece "ENV=''".

* Usa sempre echo " " (con uno spazio) a causa dei sistemi Eunice.

* Utilizzare solo test con -r, -w, -f o -d poiché questi sono gli unici switch portatili. In
particolare, evitare "test -x".

* Usa solo i programmi forniti con V7, in modo da sapere che tutti li hanno.

* Usa $contains quando vuoi eseguire il grep in modo condizionale, poiché non tutti i greps restituiscono a
stato ragionevole. Assicurati di reindirizzare l'output a /dev/null, usando '>/dev/null
2>&1'.

* Usa "if test" piuttosto che "if [...]" poiché non tutti gli sh conoscono quest'ultimo costrutto.

* Usa lo script myread per gli input in modo che possano fare escape shell e default
valutazione. La forma generale è

caso "$grimble" in
'') dflt=452;;
*) dflt="$grimble";;
che C
rp='Quanti grimble hai?'
. ./mia lettura
grimble="$ans"

* Usa lo script getfile quando chiedi un percorso di file per avere facoltativo
~ espansione del nome e controlli di integrità. Vedere l'unità Getfile.U per una descrizione completa.

* Metti sempre a

$ inizio

nella parte superiore di ogni script generato che verrà avviato o originato da
Configurazione.

* Non assumere mai comuni UNIX-ismi come il fatto che un file oggetto termini con a .o ed
che il nome di una libreria termina con .a. Usa il $_o ed $_a variabili invece (vedi
Unix.U).

* Quando esegui un test compile-link-execute, scrivilo sempre in questo modo:

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

perché alcuni sistemi richiedono che i flag di collegamento siano specificati prima della compilazione
target (ad eccezione delle librerie di collegamento finali).

* Invia messaggi importanti sul descrittore di file n. 4, utilizzando '>&4' per reindirizzare l'output.
Solo quei messaggi appariranno quando il -s l'interruttore è dato a Configurazione sul
riga di comando (modalità silenziosa).

* Cerca sempre di determinare se una funzione è presente nel modo più specifico: no
dì "if bsd" quando puoi grep libc. Ci sono molti sistemi ibridi là fuori, e
ogni caratteristica dovrebbe stare in piedi o cadere da sola.

* Cerca sempre di determinare se una caratteristica è presente nel modo più generale, in modo che
altri pacchetti possono utilizzare la tua unità.

* In caso di dubbio, imposta un valore predefinito e chiedi. Non dare per scontato nulla.

* Se pensi che l'utente abbia torto, considera il fatto che potrebbe avere ragione. Per
esempio, potrebbe eseguire Configure su un sistema diverso da quello che utilizzerà
il prodotto finale su.

Metaconfig riserva i seguenti nomi nella tua directory e, se usi un nome simile,
può essere schiacciato o avere altri effetti imprevisti:

.MT/*
Configurazione
Ricercato
Obsoleto
configure
config_h.SH
confmagic.h
U/*
MANIFEST.nuovo

Inoltre, Configure potrebbe bloccare questi nomi nella directory in cui viene eseguito:

Unità/*
config.sh
config.h

VERSIONI

Le seguenti opzioni sono riconosciute da metaconfig:

-d Attiva la modalità di debug. Non molto utile a meno che tu non stia eseguendo il debug metaconfig
stessa.

-h Stampa il messaggio di aiuto ed esci.

-k Mantieni una directory temporanea, in modo che tu possa esaminare i file di lavoro usati da
metaconfig per costruire il tuo Configurazione sceneggiatura. Utile solo durante il debug del
unità.

-m Assumi molta memoria e spazio di swap. Questo accelererà la ricerca dei simboli in
file sorgente da una notevole quantità di tempo, a spese della memoria
consumo...

-o Mappa i simboli obsoleti su quelli nuovi. Usa questo interruttore se ne hai ancora un po'
simboli obsoleti nel codice sorgente e che non vuoi (o non puoi) rimuovere
loro per ora. I simboli obsoleti vengono altrimenti ignorati, sebbene ciò
ti darà un avvertimento da metaconfig.

-s Attiva la modalità silenziosa.

-t Traccia i simboli man mano che vengono trovati.

-v Attiva la modalità dettagliata.

-w Supponiamo che il file Wanted sia aggiornato. Questo salterà il tempo e la memoria
fase di consumo della scansione del codice sorgente, alla ricerca di simboli noti. Usalo
solo quando sai che il tuo file sorgente non è cambiato rispetto a
piscina di metaconfig simboli utilizzati.

-G Fornisci anche un GNU configure-come front-end al generato Configurazione
script, da includere anche nella distribuzione. Questo è solo un involucro
attorno a Configurazione script in modo naturale, ma consente alle persone di familiarizzare con il
Strumento GNU da non perdere di fronte a una nuova distribuzione.

-L dir Sostituisci la posizione della libreria predefinita. Normalmente utile solo per metaconfig
manutentori di utilizzare localmente le unità in fase di sviluppo invece delle
quelli pubblicamente disponibili. Il dir specificato è quello che contiene le unità
U directory.

-M Consentire la produzione di a confmagic.h file per rimappare automaticamente alcuni ben-
simboli noti a qualche altra alternativa, come bcopia() essere rimappato
in modo trasparente a memcpy () quando non disponibile. Questa opzione è attivata
automaticamente quando a confmagic.h file esiste nella directory di primo livello.
Rimuovi semplicemente quel file se desideri disabilitare questa opzione in modo permanente.

-V Stampa il numero della versione ed esci.

TUTORIAL

Questa (lunga) sezione è un'introduzione a metaconfig, in cui impareremo tutte le
nozioni di base. Se sai già come usare metaconfig, puoi tranquillamente passare al prossimo
.

Panoramica
Di solito quando vuoi ottenere un pacchetto sorgente da compilare su una determinata piattaforma hai
per modificare il Makefile principale (supponendo che ce ne sia uno!), scegli un compilatore C, assicurati di
avere le librerie appropriate, quindi attivare il make comando. Se il pacchetto è ragionevolmente
ben scritto, verrà compilato (senza che un avviso sia un'opzione :-). Di per sé, l'ultimo
frase è una vera performance, poiché data la varietà di piattaforme UNIX disponibili oggi
e la diversità dei sapori, ciò significa che l'autore della confezione è andato in profondità
difficoltà a capire le scelte giuste date alcune prove standard, indovinando e scherzando
in giro con il sistema include e tipi.

Tuttavia, nonostante tutto il suo talento, l'autore non può assolutamente sapere che qualche sistema ha un
chiamata di sistema interrotta, o che qualche struttura di sistema manca di un campo altrimenti standard, o
semplicemente se un determinato file di inclusione esiste o meno. E non sto considerando l'implicito
ipotesi, come il tipo restituito da malloc () funzione o la presenza del
rinominare() chiamata di sistema per citarne alcuni. Ma quella conoscenza è necessaria per raggiungere il reale
portabilità.

Ora non abusiamo di noi stessi. L'utilizzo di tali informazioni richiede maggiori competenze, ma può
portare a programmi più portabili poiché viene quindi scritto in modo indipendente dal sistema
e si basa solo sul fatto che qualche assunzione è vera o falsa su un particolare sistema,
ogni ipotesi non è correlata l'una con l'altra. Vale a dire, non diciamo: siamo su a
Sistema BSD o siamo su un sistema USG. Comunque è troppo sfocato al giorno d'oggi. No, vogliamo
dire al codice sorgente: questo sistema non ha il rinominare() chiamata di sistema e malloc ()
restituisce a (vuoto *) valore.

Metaconfig è uno strumento che ti consentirà di fare proprio questo, con l'ulteriore vantaggio di non
dover modificare manualmente il Makefile se tutto va bene. correndo metaconfig, crei un
script di shell chiamato Configurazione. Molti sforzi sono stati dedicati allo script Configura
interni per garantire che funzionerà sul 99% delle shell esistenti disponibili a partire da questo
scrivere. Configure sonderà il sistema di destinazione, ponendo domande in caso di dubbio e
raccogliere tutte le risposte in un unico file shell, che a sua volta può essere utilizzato per
genera automaticamente Makefile configurati e file C include.

C'è solo un set limitato (ma abbastanza grande) di simboli disponibili per i tuoi script di shell
e programmi C. Sono tutti documentati nel file Glossario. Tutto quello che devi fare è imparare
su di loro e iniziare a usarli per affrontare i problemi di portabilità e configurazione. Poi,
correndo metaconfig, verrà generato uno script di configurazione adatto per il tuo pacchetto.

Lo script Configura è costituito da diverse unità (più di 300), ciascuna unità essendo
responsabile della definizione di un piccolo numero di simboli shell e/o C. Le unità sono assemblate
insieme nella fase finale, onorando il grafico delle dipendenze (un'unità potrebbe aver bisogno del risultato
di diverse altre unità che vengono poi poste prima nello script).

Simboli
I simboli sono la cosa più importante nel metaconfig mondo. Sono i più piccoli
entità riconosciuta, di solito una parola, e può essere assegnato un valore alla fine della configurazione
esecuzione. Ad esempio, il simbolo del preprocessore C HAS_RENAME è un metaconfig simbolo che
è garantito da definire se, e solo se, rinominare() la chiamata di sistema è presente. Allo stesso modo,
, il $ranlib shell variabile sarà impostata su ':' o 'ranlib' a seconda che il
chiama il ranlib programma è necessario per ordinare un file di libreria. Come funziona non lo è
importante per ora, ciò che è importante è capire che quei simboli sono dati a life
(cioè un valore) su Configurazione esecuzione.

L'uso dei simboli è relativamente semplice. In un file sorgente C, usi semplicemente il simbolo
value, come una direttiva pre-processore (ad esempio un: #ifdef HAS_RENAME) o, se il simbolo
value è una stringa, direttamente come useresti una macro in C. E in un file shell o a
Makefile, puoi fare riferimento direttamente a un simbolo di shell.

In realtà, sto mentendo, perché non è così magico come il paragrafo precedente
potrebbe suonare. In un file C, è necessario includere il file prodotto da Configura config.h file e
devi racchiudere il tuo script di shell o Makefile in un file .SH e puoi fare riferimento alla shell
simbolo solo nella parte di sostituzione delle variabili di quel file .SH. Più su questo più tardi.

Fonte File
I simboli possono apparire solo in un insieme limitato di file sorgente, perché metaconfig sarà solo
scansiona quelli quando cerchi simboli conosciuti, cercando di capire di quali unità avrà bisogno.
Puoi usare i simboli C nei file sorgente C, cioè i file con a .c, .h, .y or .l estensione e
i simboli della shell vengono cercati solo nei file .SH.

Per ottenere il valore di un simbolo, un file C deve includere lo special config.h
file, che è prodotto da Configurazione quando sono presenti i simboli C. E i file .SH vengono eseguiti
attraverso una shell, producendo un nuovo file. Tuttavia, nella sezione superiore del file .SH, il
la nostra speciale config.sh file (prodotto anche eseguendo Configurazione) è di origine e variabile
si applicano le sostituzioni. In realtà, config.h è prodotto eseguendo il metaconfig-prodotto
config_h.SH file, sempre usando la sostituzione di variabile. Quindi lo esamineremo a
un po' più da vicino poiché questo è il cuore del tutto configurazione schema...

Variabile Sostituzione
C'è un costrutto shell chiamato qui documento che abilita un comando a ricevere un input
specificato all'interno dello script stesso. Quell'input è interpretato dalla shell come un doppio
stringa tra virgolette o una singola stringa tra virgolette a seconda della forma del documento here
specificazione.

Per specificare un documento here, viene utilizzato il token '<<', seguito da un singolo identificatore. A partire dal
poi su, le restanti righe di script formano l'input per il comando, fino a qui
documento si trova su una riga da solo. Sostituzione della shell (inclusa la variabile della shell
sostituzioni) viene eseguita a meno che l'identificatore non sia racchiuso tra virgolette singole. Ad esempio:

var='prima'
tar='secondo'
echo "--> first here document:"
gatto <
var='$var'
tar='$tar'
EOM
echo "--> secondo qui documento:"
gatto <<'EOM'
eco $var
eco $catrame
EOM
echo "--> fine."

produrrà, quando viene eseguito attraverso una shell:

--> primo documento qui:
var='prima'
tar='secondo'
-> secondo qui documento:
eco $var
eco $catrame
--> fine.

Il primo documento qui ha il suo contenuto interpretato mentre il secondo viene emesso così com'è.
Entrambi sono utili in uno script .SH, come stiamo per vedere.

utilizzando .SH Script
Uno script .SH viene solitamente prodotto eseguendo il Fai SH script altro un file esistente,
trasformazione filetto in file.SH. Facciamo un solo esempio. Ecco un piccolo script
(chiamiamolo taglia grande) che stampa un singolo messaggio, la dimensione del int tipo di dati in C.
Sfortunatamente, ha il valore cablato in esso, quindi:

#!/bin/sh
intsize='4'
echo "Su questa macchina, il tipo int è $intsize bytes"

Corriamo fareSH su di esso digitando 'fareSH taglia grande'. Otteniamo un singolo intsize.SH archiviarlo
Somiglia a questo:

caso $CONFIG in
'')
if test -f config.sh; quindi TOP=.;
elif test -f ../config.sh; quindi TOP=..;
elif test -f ../../config.sh; quindi TOP=../ ..;
elif test -f ../../../config.sh; quindi TOP=../../..;
elif test -f ../../../../config.sh; quindi TOP=../../../..;
altro
echo "Impossibile trovare config.sh."; uscita 1
fi
. $TOP/config.sh
;;
che C
: Questo forza i file SH a creare il target nella stessa directory del file SH.
: Questo è così che make depend sa sempre dove trovare i derivati ​​SH.
caso "$ 0" in
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
che C
echo "Estrazione intsize (con sostituzioni variabili)"
: Questa sezione del file avrà delle sostituzioni di variabili su di essa.
: Sposta tutto ciò che necessita di sub di configurazione da !NO!SUBS! sezione a !GROK!THIS!.
: Proteggi tutti i simboli del dollaro e i backtick che non vuoi interpretare
: mettendo una barra rovesciata davanti. Puoi eliminare questi commenti.
$spitshell >intsize <
$ inizio
!GROK!QUESTO!

: Nei seguenti dollari e apici inversi non è necessario il backslash aggiuntivo.
$spitshell >>intsize <<'!NO!SUBS!'
intsize='4'
echo "Su questa macchina, il tipo int è $intsize bytes"
!NO!SOTTOSTANTI!
chmod 755 intsize
$eunicefix intsize

La prima parte di questo script (nella Custodie dichiarazione) sta cercando di individuare il config.sh
file, per estrarlo. Il $CONFIG la variabile è falsa per impostazione predefinita, per vera quando
config.sh è giàstato originato (come sarebbe il caso se questo file fosse eseguito da
entro Configurazione stesso, ma non confondiamo il problema qui).

Una volta che il config.sh file è stato sorgenti, tutti i simboli di shell definiti da Configurazione sono
impostato. Sappiamo raggiungere una seconda istruzione case, usata per cambiare la directory corrente dovrebbe a
percorso da usare per raggiungere questo programma (per esempio se dicessimo 'sh ../script/intsize.SH', noi
sarebbe prima eseguito 'cd ../script' prima di continuare). Se non capisci questo, non farlo
preoccuparsene

Ecco le cose interessanti. Questo script usa il $sputafuoco variabile, e non lo è
qualcosa che sappiamo... ancora. Se dai un'occhiata al file Glossario, lo vedrai
questa è una variabile conosciuta da metaconfig. Se rendi questo file parte della tua distribuzione
(includendolo nel file MANIFEST.new, ci torneremo più avanti) ed eseguire
metaconfig, Allora l' Configurazione script determinerà un valore adatto per questa variabile
e sarà impostato in config.sh. Lo stesso vale per $ inizio e il misterioso $eunicefix at
la fine. In un sistema ragionevole, la parte pertinente di config.sh sarebbe simile a questo:

spitshell='gatto'
startsh='#!/bin/sh'
eunicefix=':'

ah! Ci stiamo arrivando. Ora sembra familiare. Siamo di fronte a un singolo gatto comando di cui
l'input proviene da un documento here interpolato da variabili e il cui output viene reindirizzato a
taglia grande. Il valore sarà quello di $ inizio, cioè '#!/bin/sh'. Bene finora.

Quindi raggiungiamo la seconda espansione del documento qui, per ottenere il resto dello script. Questo
volta, il simbolo del documento qui è circondato da virgolette singole, quindi il contenuto sarà
aggiunto parola per parola al taglia grande file. Quindi, eseguendo 'sh intsize.SH', otteniamo il
seguente uscita:

Estrazione intsize (con sostituzioni di variabili)

e guardando il file intsize prodotto, vediamo:

#!/bin/sh
intsize='4'
echo "Su questa macchina, il tipo int è $intsize bytes"

che è esattamente quello che avevamo all'inizio. Finora, è una procedura senza operazioni...
Ma che meraviglia! Succede (pura coincidenza, fidati!), che metaconfig conosce
sulla $ int simbolo della conchiglia. Spostando l'inizializzazione di intsize nella variabile-
interpolata dello script .SH e inizializzandolo con il Configurazione-valore calcolato,
e rimuovendo gli ormai inutili commenti aggiunti da fareSH, noi abbiamo:

caso $CONFIG in
'')
if test -f config.sh; quindi TOP=.;
elif test -f ../config.sh; quindi TOP=..;
elif test -f ../../config.sh; quindi TOP=../ ..;
elif test -f ../../../config.sh; quindi TOP=../../..;
elif test -f ../../../../config.sh; quindi TOP=../../../..;
altro
echo "Impossibile trovare config.sh."; uscita 1
fi
. $TOP/config.sh
;;
che C
caso "$ 0" in
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
che C
echo "Estrazione intsize (con sostituzioni variabili)"
$spitshell >intsize <
$ inizio
intsize='$intsize'
!GROK!QUESTO!

$spitshell >>intsize <<'!NO!SUBS!'
echo "Su questa macchina, il tipo int è $intsize bytes"
!NO!SOTTOSTANTI!
chmod 755 intsize
$eunicefix intsize

Ovviamente, l'esecuzione di questo script tramite una shell produrrà nuovamente lo stesso script. Ma se
corriamo Configurazione su una macchina dove an int è memorizzato come una quantità di 64 bit, config.sh volere
set taglia grande a 8 e il taglia grande lo script avrà il valore corretto e stamperà:

Su questa macchina, il tipo int è 8 byte

che è corretto. Congratulazioni! Abbiamo appena configurato uno script di shell!!

produzione config.h
Ora possiamo dare un'occhiata al modo config.h è prodotto da config_h.SH. Lo sappiamo
running Configurazione produce un file config.sh script (come esattamente questo è fatto non è strettamente
rilevante qui, ma per i curiosi, è un'altra sostituzione del documento qui all'interno
Configurazione si). Il config_h.SH stesso è costruito da metaconfig contemporaneamente
Configurazione è, a condizione che tu faccia uso di almeno un simbolo C all'interno delle tue fonti.

Diamo un'occhiata ad alcuni casuali config_h.SH file per vedere cosa succede veramente:

caso $CONFIG in
'')
if test -f config.sh; quindi TOP=.;
elif test -f ../config.sh; quindi TOP=..;
elif test -f ../../config.sh; quindi TOP=../ ..;
elif test -f ../../../config.sh; quindi TOP=../../..;
elif test -f ../../../../config.sh; quindi TOP=../../../..;
altro
echo "Impossibile trovare config.sh."; uscita 1
fi
. $TOP/config.sh
;;
che C
caso "$ 0" in
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
che C
echo "Estrazione config.h (con sostituzioni di variabili)"
sed < config.h -e 's!^#undef!/define!' -e 's!^#un-def!#undef!'
/*
* Questo file è stato prodotto eseguendo lo script config_h.SH, che
* ottiene i suoi valori da config.sh, che è generalmente prodotto da
* eseguendo Configura.
*
* Sentiti libero di modificare qualsiasi cosa in caso di necessità. Nota, tuttavia,
* che l'esecuzione di nuovo di config.h.SH cancellerà tutte le modifiche apportate.
* Per una modifica più permanente, modificare config.sh ed eseguire nuovamente config.h.SH.
*/

/* Ora di configurazione: $cf_time
* Configurato da: $cf_by
* Sistema di destinazione: $mionome
*/

#ifndef _config_h_
#definisci _config_h_

/* copia:
* Questo simbolo è mappato su memcpy se la routine bcopy() non lo è
* disponibile per copiare le stringhe.
*/
/* HAS_BCOPIA:
* Questo simbolo è definito se la routine bcopy() è disponibile per
* copiare blocchi di memoria. Non dovresti usare questo simbolo sotto
* circostanze normali e usa invece bcopy() direttamente, che
* verrà mappato a memcpy() se bcopy non è disponibile.
*/
#$d_bcopia HAS_BCOPY /**/
#ifndef HAS_BCOPIA
#ifdef bcopia
#un-def bcopia
#endif
#define bcopy(s,d,l) memcpy((d),(s),(l)) /* mappato su memcpy */
#endif

/* HAS_DUP2:
* Questo simbolo, se definito, indica che la routine dup2 è
* disponibile per duplicare i descrittori di file.
*/
#$d_dup2 HAS_DUP2 /**/

/* I_STRINGA:
* Questo simbolo, se definito, indica al programma C che dovrebbe
* includere (sistemi USG) invece di (sistemi BSD).
*/
#$i_stringa I_STRING /**/

#endif
!GROK!QUESTO!

Nella parte superiore del file, riconosciamo il costrutto .SH standard che abbiamo già
studiato in dettaglio. Segue l'estrazione del file stesso, tramite un documento qui con
sostituzioni variabili. Tuttavia, qui non usiamo una pianura gatto ma a sete invece, poiché
dobbiamo apportare ulteriori modifiche al volo. Vedremo perché più tardi, quindi dimentichiamo
al riguardo adesso.

Ora raggiungiamo il commento principale e il file è contrassegnato con il tempo di configurazione, il
sistema di destinazione, ecc... (quelle variabili provenienti dal sourced config.sh file sono stati
istituito da Configurazione). L'intestazione del commento è seguita da una protezione "#ifndef" da proteggere
contro inclusioni multiple di questo file. Poi arriva il cuore del file...

Aiuta a saperlo $g_* ed $ io_* le variabili sono impostate su 'definire' o 'indefinito"di
Configurazione, a seconda che nel sistema sia presente una funzione o un file di inclusione o
non. Ciò significa che:

#$d_bcopia HAS_BCOPY /**/

la linea verrà estesa a:

#define HAS_BCOPY /**/

se la variabile $d_bcopy è impostata su 'define' o:

#undef HAS_BCOPY /**/

se $d_bcopy è stato impostato su 'undef', perché la funzionalità non era presente. Tuttavia, non è così
cosa viene scritto nel config.h file a causa del sete filtro che abbiamo già visto,
che trasformerà la seconda forma in:

/*#definisci HAS_BCOPY /**/

Questo è un modulo utile per la modifica successiva di config.h perché devi solo rimuovere il
iniziale '/*' se vuoi sovrascrivere Configurazionela scelta. Allo stesso modo, puoi aggiungere un singolo
'/*' all'inizio di una riga '#define' per evitare la definizione di un particolare simbolo.
Questo è il motivo per cui ogni definizione di simbolo è protetta da un '/**/' finale, per chiudere l'iniziale
commento aperto da '/*' (i commenti non sono nidificati in C).

Ora trasformare '#undef' in '/*#define' è carino, ma se vogliamo effettivamente scrivere un
'#undef', siamo bloccati... a meno che non lo scriviamo come '#un-def' e lasciamo sete aggiustalo con '#undef'
durante la produzione config.h, che è ciò che viene effettivamente fatto qui.

Lo stesso tipo di ragionamento si applica a queste due linee:

#$d_dup2 HAS_DUP2 /**/
#$i_stringa I_STRING /**/

e assumendo config.sh definisce:

d_dup2='definire'
i_string='undef'

entreremo nel prodotto config.h:

#define HAS_DUP2 /**/
/*#definisci I_STRING /**/

Chiara come l'acqua corrente? Bene!

Ora dovrebbe essere ovvio che includendo config.h in tutti i tuoi file sorgente C, arrivi a
sai cosa Configurazione ha indovinato sul tuo sistema. In effetti, usando quei simboli, sei
scrittura del codice C configurato, poiché metaconfig saprà che hai bisogno di quei simboli e lo farà
generare un adatto config_h.SH file e tutto il codice necessario in Configurazione a
calcolare un valore appropriato per loro (assegnando valori alle variabili di shell associate).

corsa Metaconfigurazione
Concentriamoci sul metaconfig programma per un po' per capire come usa le sue unità e
il codice sorgente per produrre tutti i file di configurazione necessari. Se hai intenzione di scrivere di nuovo
unità, dovresti avere una buona comprensione dell'intero schema.

Se non è presente alcun file MANIFEST.new, metaconfig proverà invece a utilizzare il file MANIFEST,
per comodità. Ovunque menzioniamo MANIFEST.new, può essere inteso come MANIFEST
a condizione che non sia presente alcun file MANIFEST.new nella radice del pacchetto.

Supponendo che il tuo file MANIFEST.new sia impostato correttamente e che elenchi tutti i file sorgente che desideri
configurare e che hai eseguito pacchetto nella directory dei sorgenti di root per creare un
.package file, puoi eseguire metaconfig e otterrai quanto segue:

$ metaconfigurazione
Localizzazione unità...
Estrazione degli elenchi di dipendenze da 312 unità...
Estrazione di nomi di file (*.[chyl] e *.SH) da MANIFEST.new...
Creazione di un file Wanted...
Scansione dei file .[chyl] per i simboli...
Scansione dei file .SH alla ricerca di simboli...
Calcolo del grafico delle dipendenze ottimali...
Creazione file make privato...
Determinazione delle unità caricabili...
Aggiornamento file make...
Determinazione dell'ordine corretto per le unità...
Creazione Configura...
Donate.

La prima fase cerca tutti i file delle unità (che terminano con .U) nella directory pubblica
prima, poi nel tuo privato. Se copi un file pubblico nella tua directory U privata
(cioè una directory chiamata U al livello più alto del tuo pacchetto), sovrascriverà il pubblico
versione. Una volta che ha un elenco di tutte le unità disponibili, le analizza ed estrae tutto
le righe ?MAKE: per conoscere le dipendenze ei simboli shell conosciuti. anche
si concentra sulle linee ?H: per conoscere i simboli C e quali simboli shell devono essere
calcolato per ottenere un valore appropriato per quel simbolo C (quindi abbiamo un altro livello di dipendenze
qui).

Successivamente, i nomi file corretti vengono estratti dai file MANIFEST.new e a Ricercato il file è
costruito: quel file elenca tutti i simboli C e i simboli di shell necessari per quel pacchetto. Noi
prima scansiona i file di tipo C per i simboli C, quindi propaga le dipendenze ai loro
simboli di shell associati (raccolti da ?H: linee). I file .SH successivi vengono scansionati e infine
tutti i simboli della shell sono noti.

Viene creato un Makefile temporaneo e metaconfig tenta di farlo make tutti i simboli della conchiglia da vedere
quali comandi (elencati nella seconda riga ?MAKE:) vengono eseguiti, e quindi quali unità sono
veramente necessario. Le unità opzionali non altrimenti necessarie vengono rimosse e viene creato un secondo Makefile
generato. Questa volta, sappiamo di tutte le unità e dei rispettivi ordini, opzionale
le unità sono state rimosse e sono stati calcolati i valori predefiniti per i loro simboli di shell. Il
Configurazione script può quindi essere generato, insieme a config_h.SH. Sono stati fatti.

convenzioni
È necessario seguire le convenzioni appropriate per far funzionare l'intero processo. C'è un caso
convenzione per le unità e una convenzione di denominazione variabile.

Tutte le unità dovrebbero avere la loro prima lettera minuscola, a meno che non siano unità speciali. Di
speciale, intendiamo che non definiscono realmente nuove variabili di shell che possono essere utilizzate dal
utente nei suoi file .SH, ma piuttosto unità che producono script o variabili di shell che devono
essere utilizzato internamente dal Configurazione sceneggiatura. Esempi tipici sono i Init.U file che è
l'inizializzazione della variabile principale, o Myread.U che produce il file mio letto script usato quasi
ovunque in Configurazione quando una domanda deve essere posta all'utente.

Le unità non speciali si suddividono quindi in due gruppi distinti: le unità che definiscono le variabili
associato a un simbolo C e unità che definiscono le proprie variabili di shell. Il primo gruppo
è ulteriormente suddiviso in variabili relative ai file di inclusione (il loro nome inizia con i_) e
variabili relative ad altre definizioni (nome che inizia con d_). Il secondo gruppo ha
nomi che rappresentano se stessi, per esempio ccU definisce il $cc variabile di shell il cui valore è
il compilatore C da utilizzare.

Le unità speciali a volte si riservano alcune variabili predefinite e restituiscono "risultati"
in altre variabili note. Ad esempio, il mio letto sceneggiatura prodotta da Myread.U
si aspetta il prompt in $rp, la risposta predefinita in $ svanito e inserisce la risposta dell'utente in $an.
Questo non è documentato in questa pagina di manuale: devi andare a guardare l'unità stessa per
capire quali variabili vengono utilizzate e come deve essere utilizzata l'unità.

utilizzando I Glossario
Il file Glossario viene prodotto automaticamente dal trucco script, che estrae il
informazioni da ?S:, ?C: e ?MAKE: righe e le riformatta in ordine alfabetico
glossario ordinato. È importante leggere il Glossario per conoscere i simboli che sei
consentito l'uso. Tuttavia, il Glossario non ti dirà come usarli. Di solito, questo è
sta a te.

Un giorno, probabilmente scriverai le tue unità e ne saprai abbastanza metaconfig
per farlo in modo rapido ed efficiente. Tuttavia, non dimenticare mai di documentare correttamente il tuo lavoro in
le linee ?S: e ?C: o altre persone non saranno in grado di riutilizzarlo. Ricorda il
tempo in cui avevi solo il Glossario e questa pagina di manuale per iniziare.

Conclusione
Ora che conosci il metaconfig nozioni di base, dovresti leggere il DESCRIZIONE sezione, quindi
salta al RIFERIMENTO sezione per conoscere tutti i dettagli cruenti come il permesso
sintassi per le linee di controllo dell'unità (righe che iniziano con un '?') o i distinti comandi MAKE
sei autorizzato a utilizzare.

RIFERIMENTO

Questa sezione documenta gli interni di metaconfig, fondamentalmente la sintassi unitaria, la speciale
unità che dovresti conoscere e i file di suggerimento.

Generale Unità Sintassi
Un'unità metaconfig è divisa in due parti distinte. La sezione di intestazione (righe che iniziano
con '?') e una sezione shell (codice da inserire nel Configurazione sceneggiatura). è
è possibile aggiungere commenti '?X:' ovunque all'interno dell'unità, ma gli altri '?' linee (anche
detto di controllo Linee) hanno una rigorosa politica di ordinazione.

Se una linea di controllo è troppo lunga, è possibile utilizzare una continuazione eludendo la finale
new-line con una barra rovesciata e proseguendo sulla riga successiva (che dovrebbe quindi essere rientrata
da spazi o tab).

Quella che segue è una descrizione formale di ciascuna delle linee di controllo. Salvo indicazione
in caso contrario, l'ordine di questa presentazione è l'ordine da utilizzare all'interno dell'unità.

?RCS: "gratis" testo
Da utilizzare per i commenti RCS, nella parte superiore dell'unità.

?X: in qualsiasi testo
Commenti di uso generale. Può apparire ovunque nell'unità, ma deve essere giustificato.
Per i commenti RCS, utilizzare il modulo ?RCS: commento.

?FARE:simbolo stratagemma: dipendenza stratagemma [+opzionale]
Questa è la prima linea di dipendenza. Il primo simbolo stratagemma dovrebbe elencare tutti i simboli
costruito da questa unità (cioè il cui valore è calcolato dalla sezione shell dell'unità).
I simboli devono essere separati da spazi. Se un simbolo definito è solo per uso interno e
non dovrebbe apparire nel generato config.sh file, allora dovrebbe essere preceduto da a
'+' (da non confondere con le dipendenze facoltative definite di seguito). Il secondo
parte dell'elenco (dopo il ':' centrale) è la dipendenza dall'unità. Dovrebbe elencare tutto
le unità speciali necessarie, così come tutti i simboli utilizzati dal guscio
implementazione. Se un simbolo è necessario ma il suo valore di configurazione non è critico,
può essere preceduto da un '+', nel qual caso si parla di dipendenza condizionale: its
l'unità corrispondente verrà caricata se, e solo se, quel simbolo è altrimenti reale
ricercato; in caso contrario verrà utilizzato il valore predefinito.

?FARE:linguetta command
Possono esserci una o più righe di comando che seguono le righe di dipendenza iniziali. Quelli
i comandi verranno eseguiti quando l'unità desidera caricarli in Configurazione. Vedere
il paragrafo sui comandi make per maggiori informazioni. Si noti che il leader linguetta
il carattere è richiesto prima di command.

?Y:disposizione
Dichiarare una direttiva di layout per questa unità. Quella direttiva potrebbe essere una delle stringhe
top, difetto or fondo (il caso non ha importanza, lo stile consigliato è quello di enunciarli
maiuscolo). Se omesso, difetto è assunto.

Questa direttiva è necessaria solo se si desidera forzare un'unità in alto o in basso
del generato Configurazione script, poiché le dipendenze dell'unità lo consentono. Importante
le domande possono quindi essere forzate all'inizio. All'interno della stessa classe di layout, unità
sono ordinate alfabeticamente con due casi speciali per le unità d_* e i_*, forzate
rispettivamente all'inizio e alla fine delle loro classi (ma queste dovrebbero appartenere al
classe predefinita).

Se forzi in alto un'unità le cui dipendenze richiedono che tutte le altre unità
precederlo, non ottieni nulla di interessante. Pertanto, tale direttiva dovrebbe davvero
essere utilizzato per aumentare la priorità di alcune unità interattive che non dipendono da molti
altri simboli visibili all'utente, come domande relative al percorso.

?S:nome_simbolo [(obsoleto simbolo stratagemma)]:
Introduce un simbolo di shell. Questa prima riga nomina il simbolo, facoltativamente seguita da a
elenco racchiuso tra parentesi e indicando l'equivalente obsoleto. Quelle obsolete
i simboli verranno rimappati al nuovo nome_simbolo se l' -o l'opzione è data a
metaconfig.

?S:in qualsiasi testo, per Glossario
Fondamentalmente un commento che descrive il simbolo della conchiglia, che verrà estratto da trucco
nel file Glossario.

?S:. Chiude il commento del simbolo della shell.

?C:nome_simbolo [~ alias] [(obsoleto simbolo stratagemma)]:
Introduce un nuovo simbolo C. Il alias nome è il nome sotto il quale verrà visualizzato il simbolo C
essere controllato, cioè se il alias si vuole il simbolo, allora quel simbolo C sarà scritto
nel config_h.SH file. Di solito, l'alias è solo '%<' (sta per il nome dell'unità)
e c'è anche una linea ?W: mappatura di un simbolo C sul alias. Anche le parti rilevanti
delle righe ?H: sono esplicitamente protette da una condizione '?%<'. Vedi il simbolo
paragrafo aliasing per maggiori dettagli. Il resto della linea è l'opzionale
obsoleto simbolo stratagemma, che elenca i vecchi equivalenti per il nuovo nome_simbolo.

?C:in qualsiasi testo, per Glossario ed config_h.SH
Fondamentalmente un commento che descrive il simbolo C, che verrà estratto da trucco
nel file Glossario e da metaconfig nella config_h.SH file se il simbolo è
voluto (o se si vuole il suo alias quando si usa l'alias del simbolo).

?C:. Chiude il commento del simbolo C.

?H:?simbolo:config_h.SH roba
Questa è la richiesta di inclusione generale in config_h.SH. La riga viene scritta solo quando
la guardia simbolo è davvero voluto. Questa forma generale è necessaria quando il simbolo C
è stato utilizzato l'aliasing. Altrimenti, se usi una delle altre forme "standard", il
la protezione viene eseguita automaticamente da metaconfig stessa.

?H:#$d_var VAR "$var"
Definisce condizionalmente il VAR simbolo C in $var quando è impostato su 'definire'. implica a
'?VAR:' condizione di guardia, e metaconfig collegamenti automatici VAR alle sue due conchiglie
dipendenze variabili (cioè entrambi $d_var ed $var sarà contrassegnato come ricercato if VAR is
usato nelle fonti C).

?H:#definire VAR [opzionale testo]
Definisce sempre il VAR Simbolo C a un certo valore. Implica un '?VAR:' condizione di guardia.
Viene creata una dipendenza shell automatica per l'unità stessa.

?H:#definire VAR(x,y,z) $var
Definisce sempre la macro VAR essere il valore di $var variabile. Sta a
unità per garantire $var ha un valore sensato. Una dipendenza automatica tra C
macro VAR e la variabile shell è stabilita, e l'intera linea è sorvegliata da an
implicito '?VAR:'.

?H:#$d_var VAR
Definisce condizionalmente VAR if $d_var è impostato per 'definire'. Implica un '?VAR:' in guardia
condizione. Viene generata una dipendenza shell automatica verso $d_guerra.

?H:#definire VAR "$var"
Assegna un valore configurato al VAR simbolo C. Implica un '?VAR:' condizione di guardia.
Viene generata una dipendenza shell automatica per link VAR ed $var.

?H:. Chiude il config_h.SH richieste di inclusione.

?M:C simbolo: C dipendenze
Introduce la definizione magica relativa al simbolo C, per confmagic.h, e definisce il
simbolo di guardia per le restanti ?M: definizioni. Questa linea implica silenziosamente
'?W:%<:C simbolo', ovvero l'unità verrà caricata in Configura se compare il simbolo C
all'interno delle fonti C, se la magia viene usata o meno. Le dipendenze C sono attivate
quando si usa la magia, per forzarne la definizione in config_h.SH. Tuttavia, se
la magia è non usato ma il simbolo C appare nella sorgente senza il necessario C
dipendenze, verrai avvisato ogni volta che il file Wanted viene creato, poiché potrebbe essere
un problema di portabilità (e anche perché l'unità è caricata incondizionatamente in
Configura ogni volta che viene utilizzato il simbolo C, indipendentemente dalle altre righe ?C: dal
unità).

?M:cpp def
Definisce la mappatura magica cpp da introdurre in confmagic.h ogni volta che l'interessato
viene utilizzato il simbolo. C'è un implicito '?sym'guardare dove sym è il nome del simbolo
definito dalla linea iniziale ?M:.

?M:. Chiude il confmagic.h richiesta di inclusione.

?W:conchiglia simbolo stratagemma:C simbolo stratagemma
Lega il destino dei simboli della conchiglia con quello dei simboli C: se qualcuno dei C
i simboli elencati sono desiderati, quindi tutti i simboli delle conchiglie sono contrassegnati come desiderati. Utile per
forzare l'inclusione di un'unità (lista dei simboli shell impostata su '%<') quando la presenza di alcuni C
viene rilevato il simbolo. L'elenco dei simboli della conchiglia può essere lasciato vuoto, per beneficiare del lato
effetto della posizione del simbolo C all'interno del preprocessore integrato (il simbolo è definito
per quel preprocessore se si trova nella sorgente). Per cercare schemi con uno spazio
in essi, è necessario citare i simboli C tra virgolette semplici, come in 'struct
fuso orario'.

?V:sola lettura simboli:lettura-scrittura simboli
Questo è metalint suggerimento e dovrebbe essere utilizzato solo in unità speciali che esportano alcune shell
variabili. Le variabili prima del ':' centrale vengono esportate in sola lettura (modificandole
emetterà un avviso), mentre altri simboli possono essere letti e modificati liberamente.

?F:file creato
Questa linea ha due scopi: è a metalint suggerimento, e anche un segnaposto per
futuro jmake utilizzo. Deve elencare tre tipi di file: quello temporaneo che sono
create per un test, quelle private UU create nella directory UU per dopo
lettura e quelli pubblici lasciati nella directory principale del pacchetto. Temporaneo
i file devono essere elencati con un '!' carattere (che significa "no! non vengono riutilizzati
dopo!"), i file UU privati ​​dovrebbero essere preceduti da un './' (che significa: per usarli, diciamo
./file, Non solo filetto), e quelli pubblici dovrebbero essere nominati così come sono.

?T:conchiglia temporanei
Un altro metalint suggerimento. Questa riga elenca tutte le variabili di shell usate come temporanee
all'interno della sezione shell di questa unità.

?D:simbolo='APPREZZIAMO'
Valore di inizializzazione per i simboli utilizzati come dipendenze condizionali. Se no ?D: la linea è
trovato, viene utilizzato un valore nullo. Il metalint il programma ti avviserà se a
il simbolo viene utilizzato almeno una volta come dipendenza condizionale e non ha un'appropriata
?D: inizializzazione. È una buona pratica aggiungere quelle righe anche per un null
inizializzazione poiché enfatizza la natura eventualmente facoltativa di un simbolo.

?O:in qualsiasi messaggio Tu volere
Questa direttiva indica che questa unità è obsoleta nel suo insieme. Ogni volta che l'uso di any
dei suoi simboli è fatto (o uso indiretto tramite dipendenze), il messaggio è emesso su
lo schermo (su stderr). Puoi inserire una o più righe, nel qual caso ogni riga lo farà
essere stampato, in ordine.

?PELUCHE:metalint suggerimenti
Vedere la metalint pagina di manuale per una spiegazione dei diversi suggerimenti che possono essere
Usato.

?DENTRO:inizializzazione codice
Il codice di inizializzazione specificato da questa riga verrà caricato nella parte superiore del
Configurazione script a condizione che l'unità sia necessaria.

C Simbolo aliasing
A volte non è possibile fare affidamento su metaconfigla propria selezione predefinita per config_h.SH
commenti e definizione del simbolo C. È qui che entra in gioco l'aliasing. Dal momento che è piuttosto
difficile da spiegare, studieremo un esempio per capire il meccanismo sottostante.

L'unità d_const.U cerca di determinare se il tuo compilatore C conosce o meno il const
parola chiave. In caso contrario, vogliamo rimappare quella parola chiave su una stringa nulla, per consentire a
compilazione del programma. Inoltre, vogliamo attivare automaticamente il test quando il const parola
viene utilizzato.

Ecco le parti rilevanti dell'unità d_const.U:

?MAKE:d_const: cat cc ccflags Setvar
?MAKE: -pick add $@ %
?S:d_const:
?S: Questa variabile definisce in modo condizionale il simbolo HACONST, che
?S: indica al programma C che questo compilatore C conosce il
?S: tipo const.
?S:.
?C:HASCONST ~ %<:
?C: Questo simbolo, se definito, indica che questo compilatore C è a conoscenza
?C: il tipo const. Non è necessario testare effettivamente quel simbolo
?C: all'interno dei tuoi programmi. Il semplice utilizzo della parola chiave "const" lo farà
?C: attivare i test necessari.
?C:.
?H:?%<:#$d_const HACONST /**/
?H:?%<:#ifndef HASCONST
?H:?%<:#define const
?H:?%<:#endif
?H:.
?W:%<:const
?LINT: imposta d_cost
?LINT:costo noto
: controlla la parola chiave const
eco " "
echo 'Verifica se il tuo compilatore C conosce "const"...' >&4
/bin/gatto >const.c <<'EOCP'
principale()
{
const char *pippo;
}
EOCP
if $cc -c $ccflags const.c >/dev/null 2>&1 ; poi
val="$definire"
echo "Sì, lo fa."
altro
val="$undef"
echo "No, non è così."
fi
imposta d_cost
eval $impostavar

Per prima cosa notiamo l'uso di una linea ?W:, che sostanzialmente dice: "Questa unità è richiesta quando il
const la parola chiave viene utilizzata in un file C.". Per rimappare condizionalmente const a un nulla
stringa in config.h, ho scelto di definire condizionalmente HACONST via $d_cost.

Tuttavia, questo solleva un problema, perché il HACONST il simbolo non verrà utilizzato nel
fonti, solo il const token è. E la "H: definizione della linea" HACONST è implicitamente
custodito da '?HASCONST'. Pertanto, dobbiamo aggiungere il vincolo esplicito '?%<' per dire
metaconfig che quelle linee dovrebbero essere incluse in config_h.SH ogni volta che il simbolo '%<'
viene ricercato (%< si riferisce al nome dell'unità, qui d_cost).

È quasi perfetto, perché la linea ?W: vorrà d_cost ogni volta che const è usato, allora
le linee ?H: verranno incluse nel config_h.SH file. Tuttavia, il commento principale (?C:
righe) allegato a HACONST è esso stesso custodito anche tramite HACONST, cioè ha un implicito
Vincolo '?HASCONST'. Da qui la necessità di alias , il HACONST simbolo su '%<'.

La parte restante dell'unità (la parte del guscio) è davvero semplice. Semplicemente
prova a compilare un programma C di esempio usando il const parola chiave. Se può, allora lo farà
definire $d_cost tramite $setvar funzione (definita da Setvar.U unità). Vedi il paragrafo
sulle unità speciali per maggiori dettagli.

Make Comandi
Sulla riga di comando ?MAKE:, puoi scrivere un comando di shell da eseguire così com'è o a
la nostra speciale -scegliere comando che è intrappolato da metaconfig e analizzato per vedere cosa dovrebbe essere
fatto. Il '-' iniziale serve solo a prevenire make dal fallimento quando il comando ritorna
uno stato diverso da zero -- non è realmente necessario poiché usiamo 'make -n'per risolvere il
dipendenze, ma ti consiglio di tenerlo nel caso diventi obbligatorio nelle versioni future.
La sintassi di scegliere il comando è:

-scegliere cmd $@ file_destinazione

where $@ èla macro standard all'interno dei Makefile che sta per il target attuale (il nome
dell'unità in costruzione, con l'estensione finale .U spogliata). Il cmd parte è il
presenti metaconfig comando da eseguire e il file_destinazione è ancora un altro parametro, il cui
l'interpretazione dipende dal cmd si. Ha anche la sua estensione .U finale spogliata e
normalmente fa riferimento a un file di unità, a meno che non inizi con './' nel qual caso fa riferimento a uno
della metaconfig file di controllo nel '.MT directory.

I comandi disponibili sono:

aggiungi Aggiunge il file_destinazione a Configurazione.

add.Config_sh
Riempie quella parte di Configurazione producendo il config.sh file. Usato solo
le variabili vengono aggiunte, quelle condizionali (dalle dipendenze condizionali) sono
saltato.

add.Null Aggiunge la sezione che inizializza tutte le variabili di shell usate ad una stringa vuota.

c_h_weed produce il config_h.SH file. Vengono stampate solo le righe necessarie.

cm_h_weed Produce il confmagic.h file. Vengono stampate solo le righe necessarie. Questo
comando è abilitato solo quando il -M interruttore è dato, o quando a confmagic.h filetto
esiste già.

chiudi.Config_sh
Aggiunge il simbolo 'EOT' finale su una linea da solo per terminare il documento qui
costruire producendo il config.sh file.

antepone Antepone il contenuto della destinazione al file_destinazione se quel file non è vuoto.

erbaccia Aggiunge l'unità a Configurazione come il aggiungere comando, ma fai alcuni test aggiuntivi
per rimuovere il '?simbolo' e '%simbolo' righe dal file_destinazione se il simbolo
non è voluto o voluto condizionatamente. Il modulo '%' viene utilizzato solo internamente da
metaconfig mentre produce i propri file .U nel '.MT'directory.

pulire come aggiungere davvero, ma esegue un'ulteriore sostituzione di macro. Il
le macro disponibili sono descritte nella Hardwired Macro paragrafo.

Come nota a margine, metaconfig genera a -cond comandare internamente per affrontare il condizionale
dipendenze. Non dovresti usarlo da solo, ma lo vedrai se effettui la scansione del
generato Makefile nel .MT directory.

Hardwired Macro
Le seguenti macro sono riconosciute dal Pulire comando e sostituito prima dell'inclusione in
Configurazione:

Il numero di revisione di base del pacchetto, derivato da .package.

La data corrente.


L'indirizzo e-mail del manutentore di questo pacchetto, derivato dal tuo
.package.


Il nome del pacchetto, come derivato dal tuo .package file.


Il livello di patch del metaconfig programma (deprecato a favore di ).


Il livello di revisione SVN del metaconfig .

Il numero di versione del metaconfig .

Queste macro sono principalmente utilizzate per identificare il metaconfig versione che ha generato un
particolare Configurazione script e per quale pacchetto è stato eseguito. L'indirizzo e-mail del
manutentore è cablato nelle istruzioni principali che Configurazione stampa all'avvio.

Recente metaconfig le versioni comprendono una sintassi molto più generale della forma:

<$variabile>

che viene sostituito al momento della generazione della configurazione dal valore di variabile preso dal tuo
.package file. Alla fine, il vecchio formato macro cablato scomparirà e <$baserev>
sostituirà in tutte le unità fornite.

Special Unità
Le seguenti unità speciali vengono utilizzate per fattorizzare il codice e fornire un livello superiore
funzionalità. Producono uno script di shell che può essere prelevato o una shell
variabile che può essere eval'ed. Il passaggio dei parametri avviene tramite variabili note, sia
con nome o anonimo come $1, $2, ecc... (che può essere facilmente impostato tramite la shell set
operatore). quando Configurazione esegue, crea e va in a UU directory, quindi ogni
lo script prodotto si trova lì e non interferisce con i file del pacchetto.

Ecco le unità speciali che dovresti conoscere e il modo di usarle.

Cppsym.U
Questa unità produce uno script di shell chiamato Cppsym, che può essere utilizzato per determinare
se qualsiasi simbolo in una lista è definito dal preprocessore C o dal compilatore C che hai
specificato. Può determinare lo stato di qualsiasi simbolo, sebbene i simboli in
(elenco attributi) sono più facilmente determinabili.

Csim.U
Questo imposta la variabile di shell $csym, usata internamente da Configurazione per verificare se a
dato il simbolo C è definito o meno. Un uso tipico è:

set simbolo risultato [-fva] [precedente]
eval $csim

Questo imposterà il colpevole variabile a 'vero' se la funzione [-f], variabile [-v] o
array [-a] è definito, 'false' altrimenti. Se viene fornito un valore precedente e il -r
l'interruttore è stato fornito a Configurazione (Vedi Configurazione Opzioni paragrafo), allora che
il valore viene riutilizzato senza mettere in discussione.

Il modo in cui viene eseguito questo calcolo dipende dalla risposta che l'utente dà alla domanda
Configurazione chiederà se deve eseguire un nm estrazione o meno. Se la
l'estrazione è stata eseguita, l'unità guarda semplicemente attraverso l'elenco dei simboli, altrimenti
esegue un test del collegamento di compilazione, a meno che -r è stato dato per riutilizzare il calcolato in precedenza
valore, naturalmente...

Fine.U
Copiando questa unità nel tuo privato U directory e aggiungendo le dipendenze da
?MAKE: line, puoi forzare il caricamento di una data unità in Configurazione anche se non lo è
altrimenti voluto. Alcune unità possono essere forzate solo in Configurazione quel modo.

Filexp.U
Questa unità produce uno script di shell filexp che espanderà i nomi dei file che iniziano con
tilde. Un uso tipico è:

exp_name=`./filex $name`

per assegnare il nome del file espanso in nome_exp.

Trovahdr.U
Questa unità produce un trova hdr script che viene utilizzato per individuare i file di intestazione in
$usrin o altri luoghi sconosciuti che utilizzano le funzionalità cpp. Lo script è dato an
include il nome di base del file come "stdio.h" o "sys/file.h" e restituisce il percorso completo di
il file inlcude e uno stato zero se trovato, o una stringa vuota e uno stato diverso da zero
se non è stato possibile individuare il file.

Getfile.U
Questa unità produce un po' di codice shell che deve essere acquisito per ottenere un file
nome ed eseguire alcuni controlli di integrità. Facoltativamente, viene eseguita un'espansione ~name.

Per utilizzare questa unità, $rp ed $ svanito deve contenere la domanda e la risposta predefinita, che
sarà passato così com'è al mio letto sceneggiatura (vedi prossimamente Myread.U). Il $ fn
variabile controlla l'operazione e il risultato viene restituito in $an.

Per individuare un file o una directory, inserisci 'f' o 'd' in f~/. Se appare un '~', allora ~nome
è consentita la sostituzione. Se viene visualizzato un '/', vengono accettati solo i nomi di percorso assoluti e
~le sostituzioni dei nomi vengono sempre espanse prima di tornare. Se viene specificato '+',
i controlli di esistenza vengono saltati. Se 'n' appare all'interno $ fn, allora l'utente è autorizzato a
rispondi "nessuno".

Di solito, a meno che tu non abbia chiesto la portabilità, la sostituzione del ~nome avviene quando richiesta.
Tuttavia, ci sono alcune volte in cui desideri bypassare la portabilità e forzare il
sostituzione. Puoi usare la lettera 'e' (espandi) per farlo.

Se viene utilizzato il tipo speciale 'l' (localizza), allora il $ fn la variabile deve terminare con un ':',
seguito da un nome di base del file. Se la risposta è una directory, il nome base del file sarà
aggiunto prima di verificare l'esistenza del file. Questo è utile nelle domande in stile localizzazione
come questo:

dflt='~notizie/lib'
: non è necessario specificare 'd' o 'f' quando si usa 'l'
fn='l~:attivo'
rp='Dov'è il file attivo?'
. ./prendi il file
attivo="$an"

Inoltre, la lettera 'p' (percorso) può essere usata insieme a 'l' per dire
prendi il file che una risposta senza '/' dovrebbe essere accettata, supponendo che lo farà
essere nel PERCORSO di tutti nel momento in cui questo valore sarà necessario.

Utile anche la possibilità di specificare un elenco di risposte che dovrebbero essere accettate
parola per parola, aggirando tutti i controlli. Questo elenco deve essere tra parentesi e voci
devono essere separati da virgole, senza spazi intercalari. Non dimenticare di citare il
stringa risultante poiché le parentesi sono significative per la shell. Ad esempio:

dflt='/bin/install'
fn='/fe~(installa,./installa)'
rp='Usi quale programma di installazione?'
. ./prendi il file
install="$ans"

consentirebbe all'utente di specificare solo percorsi completi che si riferiscono a file esistenti,
ma consenti comunque le risposte speciali "install" e "./install" così come sono (supponendo che
ovviamente qualcosa si occuperà di loro specialmente più avanti nella catena poiché lo fanno
non conforme al quadro generale previsto).

Se la risposta alla domanda è "nessuna", i controlli di esistenza vengono saltati e
viene restituita la stringa vuota. Nota che poiché prendi il file chiamate mio letto internamente, tutto
le funzioni disponibili con mio letto applicare qui a.

Se è necessario un valore completamente espanso (ad esempio in un Makefile), puoi usare
, il $ssp variabile che è sempre impostata correttamente da prendi il file come l'espanso
versione $an. Ovviamente, non espanderà ~name se non lo permetti nel
primo posto nella $ fn variabile.

Inhdr.U
Questa unità produce il $indr variabile di shell, usata internamente da Configurazione controllare
se esiste o meno una serie di intestazioni. Un uso tipico è:

imposta intestazione i_header [ header2 i_header2 ... ]
valore $inhdr

Questo stamperà un messaggio, dicendo se l'intestazione è stata trovata o meno e imposta il
i_intestazione variabile di conseguenza. Se viene specificata più di un'intestazione e la prima
l'intestazione non viene trovata, proviamo con la successiva, finché l'elenco non è vuoto o ne viene trovata una.

Inlibc.U
Questa unità produce il $inlib variabile di shell, usata internamente da Configurazione controllare
se una data funzione C è definita o meno. Un uso tipico è:

imposta la funzione d_func
eval$inlibc

Questo stamperà un messaggio, dicendo se la funzione è stata trovata o meno e impostata
$d_funzione di conseguenza. Internamente, utilizzava il $ csim routine.

Loc.U
Questa importante unità produce uno script di shell loc che può essere usato per scoprire dove
in un elenco di directory si trova un determinato file. Il primo argomento specifica il file su cui
essere individuato, il secondo argomento è ciò che verrà restituito se la ricerca fallisce, e il
gli argomenti rimanenti sono un elenco di directory in cui eseguire la ricerca del file. Per
esempio:

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

imposterebbe $ svanito a X se no sendmail.cf il file è stato trovato nelle directory elencate,
o qualcosa del genere /usr/lib/sendmail.cf su alcuni sistemi. Guarda anche Getfile.U.

MailAutore.U
Questa unità deve essere inclusa nella linea "MAKE: of your private End.U to make"
dentro Configurazione. Offre all'utente di registrarsi all'autore, facoltativamente
essere avvisato quando arrivano nuove patch o riceverle automaticamente quando vengono rilasciate.
È necessario installare mailagente per farlo (almeno la versione 3.0).

MailList.U
Questa unità deve essere inclusa nella linea "MAKE: of your private End.U to make"
dentro Configurazione. Offre all'utente la possibilità di iscriversi o annullare l'iscrizione a una mailing list
dove si sta svolgendo la discussione relativa al pacchetto. devi correre pacchetto
e rispondi alle domande relative alla mailing list per impostare le variabili corrette nel tuo
.package prima che questa unità possa diventare operativa.

Myinit.U
Copia questa unità nel tuo privato U directory per aggiungere i propri valori predefiniti ad alcuni
variabili interne. Questa unità è caricata in Configurazione dopo tutto l'impostazione predefinita
inizializzazioni sono state fatte.

Myread.U
Questa unità produce il mio letto script di shell che deve essere sorgente per fare un
leggere. Consente l'escape della shell, l'assegnazione predefinita e la valutazione dei parametri, come
documentato nell'unità Instruct.U. Consente inoltre l'impostazione dinamica del -d opzione,
che verrà utilizzato per il resto dell'esecuzione dello script.

Per utilizzare questa unità, $rp deve contenere la domanda e $ svanito dovrebbe contenere il valore predefinito
Rispondere. La domanda verrà stampata dallo script stesso e verrà restituito il risultato
nel $an variabile.

Ecco un uso tipico:

dflt='y'
rp='Domanda?'
. ./mia lettura
valore = "$ ans"

Vedere l'unità stessa per ulteriori informazioni.

Oldconfig.U
Questa unità deve essere parte della tua dipendenza? MAKE: line quando alcune delle tue unità ci provano
per riutilizzare un vecchio valore di simbolo. Questa unità è responsabile dell'ottenimento delle vecchie risposte
da config.sh o fornendo suggerimenti utili durante l'esecuzione su una determinata piattaforma per il
prima volta. Vedi il Configurazione Suggerimenti paragrafo per ulteriori informazioni sui suggerimenti.

Prefisso.U
Lo scopo di questa unità è rilevare le modifiche nella directory del prefisso di installazione per
ricalcolare automaticamente i valori predefiniti adatti dalle risposte precedenti. Si basa sul
valore del $vecchioprefisso variabile che contiene la directory del prefisso precedente quando
modificato ed è vuoto altrimenti. Ad esempio, se il prefisso è stato modificato da /optare a
/ Usr / local, quindi la directory di installazione binaria precedente verrà modificata da
/opt/bin a / Usr / local / bin, o rimarrà invariato se fosse, ad esempio, /bidone.

Devi chiamare set prima di emettere un eval on $prefisso, Quali:

imposta dflt var [dir]
eval $ prefisso

che stabilirebbe $ svanito a $var or $prefisso/dir a seconda che il prefisso sia rimasto
lo stesso o no. Se dir è la stringa nessuna, un singolo valore di spazio in $ svanito è tenuto come-
è, anche quando il prefisso cambia. Se dir è omesso, allora $ svanito è impostato su un vuoto
stringa se il prefisso è cambiato, in $var altrimenti.

Prefisso.U
L'intento di questa unità è simile a quello di Prefixit.U, cioè aiuta a riparare il
stringa predefinita per accogliere le modifiche al prefisso. Tuttavia, la variabile shell $prefisso,
quando valutato, ripristinerà solo le espansioni di ~nome, se il prefisso dovrebbe usare tale escape
meccanismo. Usalo come:

imposta dflt
eval $prefisso

prima di chiedere tramite prendi il file ad esempio. Se il prefisso non fa uso di ~name
espansione, allora quanto sopra sarà un no-op sul y variabile, naturalmente.

Typedef.U
Questa unità produce il $ typedef variabile di shell, usata internamente da Configurazione controllare
se esiste o meno un typedef. Un uso tipico è:

set typedef val_t default [ include ]
eval $ typedef

Questo imposterà la variabile val_t al valore di difetto se il typedef non è stato trovato
tra quelli elencati include file, o to typedef se trovato. Se non ci sono file di inclusione
specificato, l'unità cerca in solo. Se specifichi alcune inclusioni, solo
quelli sono guardati.

Unix.U
Lo scopo di questa unità è definire alcuni degli UNIX-ismi più comuni tramite variabili
che può essere modificato dalla riga di comando o tramite appositi file di suggerimento. In particolare,
$_exe, $_o ed $_a sono impostati. Tutte le unità dovrebbero fare riferimento a $_o e non farlo .o direttamente.
Il '.' fa parte di queste variabili.

Setvar.U
Questa unità produce la variabile, che viene utilizzata internamente da Configurazione per impostare a
definire/undef valore a un dato simbolo, emettendo un avviso quando cambia improvvisamente
da un valore precedente. Ad esempio:

val="$definire"
imposta variabile_d
eval $impostavar

Se il precedente $d_variabile il valore non era nullo e $ valore è diverso, un "whoa"
viene emesso un avviso.

Whoa.U
Questa unità produce il whoa script, che emette un avviso quando il APPREZZIAMO in variabile
il cui nome è $var non è lo stesso del suo vecchio valore precedente contenuto in $ era. Su
ritorno, $td ed $ tu mantenere il valore corretto per definire or indefinito la variabile. Vedere
esempi in Inlibc.U.

incorporato Pre-processore
Ogni unità da includere in Configurazione viene eseguito tramite un pre-processore integrato. Pre-
le istruzioni del processore sono introdotte dal carattere '@' ('#'èil commento della shell
carattere). Funziona semplicemente come fa il preprocessore C ma consente shell e perl
scappa. Ecco le funzioni disponibili:

@Se espressione
If espressione è vero, continua a caricare il codice fino a @end, @elsif o @else.

@else espressione
Scelta alternativa. Se espressione è vero, continua a caricare il codice fino a @end,
un altro @elsif o @else.

@else Codice predefinito da caricare se @if espressione era falso e nessuno dei
facoltativo @elsif abbinato. Carica fino a @end.

@end Chiude l'istruzione di caricamento condizionale aperta da @if.

@definire simbolo
Dice al pre-processore che simbolo è definito d'ora in poi.

Il condizionale espressione può includere nomi di simboli (il valoreèvero se si vuole un simbolo oppure
definito tramite @definire o fughe shell/perl. Questi atomi possono essere combinati usando il
operatori booleani tradizionali '!' per negazione, '&&' per and logica e '||' per logica
o.

Il testo racchiuso tra parentesi singole è un test di shell, mentre il testo tra doppie parentesi è
una prova di perla. Ovvero le espressioni:

{ conchiglia testo }
{{ perl testo }}

sono tradotti in:

if conchiglia testo >/dev/null 2>&1; quindi esci 0; altrimenti uscita 1; fi
if (perl testo) {uscita 0;} altrimenti {uscita 1;}

e lo stato di uscita viene utilizzato nel modo standard per ottenere un valore booleano, ovvero 0 è vero e
tutto il resto è falso. Nota che solo condizioni semplici possono essere espresse in perl, finché
un codice complesso può essere caricato all'interno metaconfig ed eseguito.

Il pre-processore integrato può essere utilizzato per mettere a punto alcune unità (vedi d_gethname.U per
esempio complesso) a seconda dei simboli effettivamente utilizzati dal programma o dai file
presente nella distribuzione. Ad esempio, il Oldconfig.U usa un test come:

@if {test -d ../suggerimento}

ed Configurazione conterrà codice dipendente dall'hint solo se c'è un suggerimenti nella directory
directory di primo livello del pacchetto. Si noti che i test vengono eseguiti dall'interno del '.MT'cartella,
quindi il necessario '../' nel test.

Il pre-processore può essere utilizzato anche per evitare di inserire codice inutile quando un simbolo non lo è
definito. Le unità che definiscono più di un simbolo possono essere protette in questo modo (poiché l'unità è
caricato nel suo insieme) raccogliendo il codice dipendente dal simbolo all'interno di una coppia @if/@end. Per
esempio:

@se io_TIME || I_SYS_TIME || I_SYS_TIME_KERNEL
need_time_h='vero'
@altro
need_time_h='falso'
@fine

verificherà se il codice sorgente fa uso di uno dei tre simboli che controllano
, il tempo.h or sys/ora.h inclusione e definire di conseguenza il simbolo della shell. che dà
Configurazione un feedback su ciò di cui hanno bisogno le fonti ed evitare l'inconveniente di aver riparato
unità congelate.

Tramite le righe '?W:' puoi ottenere combinazioni interessanti. Ad esempio, il i_tempo.U unità
ha bisogno di sapere se le sorgenti C fanno un uso del struct fuso orario genere. Dunque,
la linea:

?W::fuso orario

è usato per il suo effetto collaterale di definire il simbolo fuso orario per il preprocessore. Il
il codice dell'unità può quindi dire:

@se fuso orario
per s_timezone in '-DS_TIMEZONE' ''; fare
@altro
s_timezone=''
@fine

... codice usando s_timezone ...

@se fuso orario
fatto
@fine

e avere un ciclo extra provando due valori successivi per il s_fuso orario variabile, ma solo
se necessario.

Obsoleto Simboli
I simboli obsoleti vengono conservati per facilitare la transizione con i vecchi metaconfig unità. Salvo che
, il -o l'interruttore è passato a metaconfig verranno ignorati. Tuttavia, un Obsoleto il file sarà
essere generato, dicendoti quali file stanno facendo uso di quei simboli obsoleti e cosa
sono i nuovi simboli da utilizzare.

La durata dei simboli obsoleti è di una revisione completa, ovvero verranno rimossi quando il
viene emessa la revisione di base successiva (ovviamente gli aggiornamenti delle patch non contano). Pertanto, è
saggio tradurre le tue fonti e iniziare a utilizzare i nuovi simboli il prima possibile.

Configurazione Suggerimenti
Può capitare che la logica di configurazione interna faccia delle scelte sbagliate. Per
esempio, su alcune piattaforme, il vfork() la chiamata di sistema è presente ma interrotta, quindi dovrebbe
non essere utilizzato. Non è possibile includere tale conoscenza nelle unità stesse, perché
potrebbe essere un problema temporaneo che il venditore alla fine risolverà o qualcosa che
è stato introdotto da un nuovo aggiornamento del sistema operativo.

Ad ogni modo, per tutti quei piccoli problemi che sono troppo specifici del sistema, metaconfig
fornisce supporto per i file di suggerimento. Per usarlo, devi creare un suggerimenti nella directory
la directory di primo livello del pacchetto e di averla quando si esegue metaconfig. Questo caricherà il
parte relativa al suggerimento da Oldconfig.U.

Da quel momento in poi, puoi preimpostare alcune delle variabili della shell Configurazione utilizza in un sistema operativo specifico
file .sh. C'è un codice in Oldconfig.U che cerca di indovinare quali file di suggerimento sono necessari per
calcolare un nome standard in base al nome del sistema operativo, al nome del kernel, alla versione
numero, ecc... Poiché è probabile che queste informazioni cambino rapidamente, non le sto documentando
qui. Devi decodificare il codice da Oldconfig.U.

Quando rilasci il pacchetto per la prima volta, la directory del file dei suggerimenti dovrebbe essere vuota. Se la
gli utenti del tuo pacchetto si lamentano di avere problemi con Configurazione impostazioni predefinite su a
particolare sistema, devi vedere se questo è un problema specifico della piattaforma o un
quello generale. Nel primo caso, è il momento di introdurre un nuovo file di suggerimento, mentre nel
quest'ultimo, l'unità corrispondente dovrebbe essere rivista.

Ad esempio, è noto che i sistemi SGI hanno un guasto vfork() chiamata di sistema, a partire da questo
scrivere. E il nome del file di suggerimento corrispondente è sgi.sh. Quindi tutto ciò che devi fare è creare
a suggerimenti/sgi.sh file in cui scrivi:

d_vfork="$definire"

che rimappa sempre vfork on forcella (Vedi d_vfork.U). Durante l'esecuzione su sistemi SGI per il
prima volta, Configurazione rileverà che c'è un suggerimenti/sgi.sh file, e che siamo su
una macchina IRIX (il nome del kernel è spesso /irix), quindi proporrà sgi come
possibile indizio. Se l'utente lo accetta, e poiché il $d_vfork il valore viene modificato tramite il
$setvar chiama, a Whoa! verrà emesso per avvisare che stiamo per sovrascrivere il valore
calcolato da Configurazione.

Nota che non devi fornire contro tutti i i suggerimenti conosciuti da Oldconfig.U. Se un file di suggerimento è
mancante, non verrà proposto come possibile scelta. I test euristici sono stati eseguiti per calcolare
i possibili suggerimenti candidati sono traballanti. Se hai nuovi valori o test diversi, per favore
speditemeli...

Override scelte
Se crei un file config.over file nella directory di primo livello, Configurazione ti chiederò se tu
desidera caricarlo per sovrascrivere i valori predefiniti. Questo viene fatto prima della creazione del
config.sh file, quindi ti dà la possibilità di correggere i valori memorizzati lì.

Questo è distinto dall'approccio dei suggerimenti in quanto è un file locale, che l'utente è
libero di creare per il proprio uso. Non dovresti fornire un file del genere da solo, ma lascia che
l'utente conosce questa possibilità.

Configurazione Opzioni
I Configurazione script può essere chiamato con alcune opzioni specificate sulla riga di comando, per
modificare leggermente il suo comportamento. Ecco le opzioni consentite:

-d Usa le impostazioni predefinite per tutte le risposte.

-e Vai avanti senza mettere in discussione la produzione di config.sh.

-f filetto Usa il file specificato come configurazione predefinita. Se questo interruttore non viene utilizzato,
la configurazione è presa da config.sh, quando presente.

-h Stampa il messaggio di aiuto ed esci.

-r Riutilizzare il valore dei simboli C se possibile. Questo salterà il costoso nm simbolo
estrazione. Se utilizzato la prima volta (senza file di configurazione precedente),
Configurazione cercherà di compilare e collegare un piccolo programma per saperne di
la presenza o l'assenza di un simbolo.

-s Modalità silenziosa. Solo le stringhe stampate sul descrittore di file #4 verranno visualizzate sul
schermo (questi sono i messaggi importanti). Non è possibile spegnere completamente
qualsiasi output, ma puoi usare 'Configurazione -ders > / dev / null 2> e 1' per avere un pieno
esecuzione batch senza output e senza necessità di interazione da parte dell'utente.

-D simbolo=valore
Predefinito simbolo sopportare lo specificato APPREZZIAMO. È anche possibile utilizzare '-D
simbolo' che utilizzerà un valore predefinito di 'definire'.

-E Stop alla fine delle domande di configurazione, dopo aver prodotto un
config.sh. Questo non eseguirà alcun 'make dipendere' o estrazione di file .SH.

-K Utente esperto. Quando usi questa opzione, sai cosa stai facendo e
quindi, il config.sh il file verrà sempre gestito come se fosse destinato a essere
riutilizzato, anche se potrebbe essere stato generato su un sistema alieno. anche
impedisce l'interruzione quando Configurazione rileva un compilatore C inutilizzabile o un set sbagliato
di bandiere C. Ulteriori scorciatoie potrebbero essere attivate anche da questa opzione nel
futuro. Questa opzione è documentata nel Configurazione messaggio di utilizzo, per ricordarcelo
sulla sua esistenza, ma si spera che la descrizione fornita sia abbastanza criptica.
:-)

-O Consenti valori specificati tramite a -D or -U per sovrascrivere le impostazioni da qualsiasi caricato
file di configurazione. Questo non è il comportamento predefinito poiché l'override lo farà
non essere propagato a variabili derivate da quelle che stai attualmente modificando.
Naturalmente, senza -O, l'impostazione viene eseguita solo quando non è presente alcun file di configurazione
caricato, il che è sicuro poiché le variabili derivate non sono state ancora calcolate...

-S Eseguire la sostituzione delle variabili su tutti i file .SH. Puoi abbinarlo al
-f passare per propagare qualsiasi configurazione che ti piace.

-U simbolo=
Preimpostazioni simbolo portare un valore vuoto. È anche possibile utilizzare '-U simbolo'
che imposterà simbolo a 'undef'.

-V Stampa il numero di versione del metaconfig che ha generato questo Configurazione copione
e uscita.

corsa Ambiente
All'avvio, Configurazione crea un locale UU directory e viene eseguito da lì. La directory
viene rimosso al termine di Configura, ma ciò significa che devi eseguire lo script da un punto in cui
puoi scrivere, cioè non da un file system di sola lettura.

Puoi correre Configurazione a distanza però, come in:

../pacchetto/Configura

per configurare sorgenti che non sono presenti localmente. Tutti i file generati verranno inseriti
la directory da cui stai eseguendo lo script. Questa magia è fatta grazie a src.U
unità, che sta impostando il $sorgente ed $rsrc variabili per puntare alle origini del pacchetto. Quella
percorso è completo o relativo, a seconda che Configurazione è stato invocato tramite un or completo
percorso relativo.

Dall'interno del UU sottodirectory, puoi usare $rsrc per accedere ai file sorgente (unità
riferendosi ai file di origine i suggerimenti sui collegamenti devono sempre utilizzare questo meccanismo e non presumere che
file è presente nella directory padre). Tutti i Makefile dovrebbero usare la variabile $src
come puntatore ai sorgenti dalla parte superiore della directory build (dove Configurazione viene eseguito),
direttamente o tramite un'impostazione VPATH.

Durante la corsa Configurazione in remoto, i file .SH vengono estratti nella directory build, non
nell'albero di origine. Tuttavia, richiede una sorta di a make supporto per poter compilare
cose in una directory di compilazione mentre i sorgenti si trovano altrove.

utilizzando magia ridefinizioni
Facendo uso del -M switch, alcune rimappature magiche potrebbero aver luogo entro un confmagic.h
file. Quel file deve essere incluso dopo config.h, certo, ma anche dopotutto il
altri file di inclusione necessari. Vale a dire:

#include "config.h"
...
... Altro inclusioni ...
...
#include "confmagic.h"

Tipicamente, confmagic.h tenterà di rimappare copia() on memcpy () se no copia() is
disponibile localmente, o trasformare vfork ai miglioramenti forcella quando necessario, rendendo quindi inutile
preoccuparsi del HAS_VFORK simbolo.

Questa magia di configurazione è documentata nel file Glossary.

Unità Modelli
C'è una serie di modelli di unità nel metaconfig directory dei sorgenti, che hanno lo scopo di
essere utilizzato da un programma (non ancora scritto) per produrre rapidamente nuove unità per vari tipi di
situazioni. Nessuna documentazione per questo progetto incompiuto, ma ho pensato di menzionarlo
nella pagina di manuale nel caso tu voglia farlo da solo e poi contribuire...

AUTORI

Larry Wall[email protected]> per la versione 2.0.
Harlan Stenn[email protected]> per importanti estensioni di unità.
Raffaello Manfredi[email protected]>.
Molti altri contributori per il metaconfig unità. Vedere il file di credito per un elenco.

Usa metaconfig online usando i servizi onworks.net