makepp_scanning - Online nel cloud

PROGRAMMA:

NOME

makepp_scanning -- In che modo i ritrovamenti di makepp includono file e altre dipendenze nascoste

DESCRIZIONE

Makepp può determinare dipendenze o destinazioni aggiuntive per determinati comandi che conosce
qualcosa a proposito di. Questo è particolarmente importante per la compilazione C/C++, dove lo è anche
soggetto a errori per elencare manualmente tutti i file di inclusione da cui dipende un determinato file di origine.
Osservando il comando di compilazione e gli stessi file sorgente, makepp è in grado di
determinare con precisione quali file oggetto devono essere ricostruiti quando alcuni includono modifiche ai file.

Esempio: data una regola

foo.o: # Di solito %.o: %.c, solo per illustrazione
time -p /bin/libtool -bar /usr/bin/cc -c -I da qualche parte foo.c

makepp sa che "time" e "libtool" devono essere saltati e che "cc" è il comando effettivo
da analizzare qui. Lo capisce foo.c è il file di input e quindi una dipendenza di
questa regola. Inoltre eseguirà la scansione di quel file alla ricerca di istruzioni include, anche in
elenco da qualche parte, perché ha compreso le opzioni del comando.

In realtà ci sono tre passaggi per ciò che è storicamente noto come scansione:

1. L'azione della regola è suddivisa in righe (le righe di continuazione contano come una). Ogni linea
(eccetto i builtin e i blocchi Perl) è lessicalmente analizzato come uno o più comandi Shell.
I reindirizzamenti vengono riconosciuti come input o output di questa regola. La prima parola di ciascuno
viene cercato il comando (con la sua parte di directory ma, se non viene trovato, di nuovo senza di essa) per
trova un parser per esso. Queste diventano dipendenze facoltative, vengono costruite se possibile,
ma ignorato se non trovato, poiché makepp non può sapere quale parte di un comando complesso è
effettivamente eseguito.

I comandi tra apici inversi vengono analizzati ma non eseguiti. (Spesso l'esecuzione è importante,
ma questa sarebbe una grossa interferenza da parte di makepp.) È meglio evitarli.
Invece fai in modo che makepp esegua il comando al massimo una volta assegnandolo in questo modo speciale:

XYZFLAGS ;= $(shell pkg-config --cflags xyz)

Attualmente esiste solo una classe lexer, che comprende Bourne Shell. Migliorare
gestire C Shell o "command.com", potrebbero essere create sottoclassi. Tuttavia, molta sintassi è
abbastanza simili da non giustificarlo. Contattaci se vuoi contribuire anche tu.

2. Per i comandi noti il ​​corrispondente command parser (chiamato anche parser)
analizza le opzioni e gli argomenti importanti. Quelli disponibili sono descritti di seguito.

Anche se non è stato trovato alcun parser specializzato, quello generico rende eseguibile il comando
un input di questa regola. Puoi cambiarlo con --no-path-executable-dependencies
opzione di comando.

3. Se il parser ha riconosciuto dei file di input, questi vengono inviati al scanner scelto dal
analizzatore. Trova ulteriori input cercando "#include" o dichiarazioni comparabili.

Questo è il passaggio più costoso. Tutti i risultati vengono memorizzati nella cache per evitare di ripeterli
inutilmente.

Se makepp pensa che stia compilando un sorgente C/C++ ma non riesce a trovare un parser, darà un
messaggio di avviso per informarti. Questo di solito significa che hai seppellito il tuo comando del compilatore
troppo immerso nell'azione perché makepp lo trovi. Ad esempio, ho visto regole come questa:

%.o: %.c
@echo Compilando $< ora; dark_wrapper gcc -c $< $(CFLAGS) -o $@

Le prime parole delle azioni qui sono "echo" e "obscure_wrapper", per le quali ci sono
nessun parser, quindi makepp non cercherà i file include in questo caso. Puoi ignorare il
comando prefissato da:

register-parser oscura_wrapper skip-word

Le sezioni seguenti documentano i parser e gli scanner incorporati. Nel nome puoi
usa "-" in modo intercambiabile con "_".

SCANNER (PARSER)

I vari scanner devono essere scelti da un parser di comandi, che è dato tra parentesi:

C / C ++ compilazione (c-compilazione, compilazione gcc)
Lo scanner C/C++ gestisce entrambe le lingue indifferentemente. In effetti guarda solo
istruzioni del preprocessore, quindi può essere utilizzato per parecchie lingue. Il parser che
lo attiva ha una variante speciale per le molte opzioni di gcc, che viene scelta se il
nome comando include la stringa "gcc" o g++. Se compilatori per altre lingue con C
il preprocessore usa le stesse opzioni del compilatore C (almeno "-I"), quindi questo parser funziona
bene.

Guarda il comando per le opzioni "-Idir" specificando il percorso di inclusione o le opzioni "-Ldir"
specificando il percorso del collegamento. Quindi esegue la scansione di qualsiasi file sorgente per le direttive "#include" e
guarda anche la riga di comando per vedere se ci sono file sorgente o librerie menzionate
che non sono elencati come dipendenze. Li riconosce dalla loro estensione.

Questo scanner fornisce un messaggio di avviso se i file inclusi con "#include "file.h"" non lo sono
trovato, o non compilabile da makepp, nel percorso di inclusione, o nella directory che contiene il
file che è "#include"ing, o in / usr / include. Non viene dato alcun avviso se un file è incluso
con "#include " non è stato trovato. Makepp presume che sia in qualche sistema include
directory che il compilatore conosce e che i file nel sistema includono directory
non cambierà.

Inoltre, i file in / usr / include, /usr/local/include, /usr/X11R6/includee qualsiasi altro
le directory che non sono scrivibili non vengono scansionate per vedere cosa includono. Makepp assume
che questi file non cambieranno. (Se stai eseguendo come root, il test di scrivibilità è
eseguito con l'UID e il GID della directory da cui hai eseguito makepp. Questo è così compilando
un programma come un normale utente e quindi eseguire "makepp install" come root non causerà extra
directory da scansionare.)

Questo è uno scanner abbastanza semplice. Si confonderà se fai cose del genere:

#ifdef INCLUDE_QUESTO
#include "this.h"
#endif

perché non conosce i condizionali del preprocessore. Questo di solito è innocuo; esso
potrebbe causare l'etichettatura di ulteriori file aggiuntivi come dipendenze (a volte causando
ricostruzioni non necessarie), oppure potrebbe far sì che makepp avverta che il file include non lo era
trovato. Puoi ignorare i messaggi di avviso o inserire un file vuoto "this.h"
lì per chiudere il trucco.

Se il tuo compilatore ha un nome strano, puoi dire uno dei due

register-parser oscura_c_compiler c-compilation
register-parser oscura_gcc_alias gcc-compilation

Embedded SQL C / C ++ compilazione (compilazione esql)
Questi comandi, forniti con i vari database, preelaborano sezioni speciali in
altrimenti sorgenti simili a C/C++ e producono intestazioni e sorgenti C/C++. Questo trova EXEC SQL
Direttive INCLUDE "filename" o $INCLUDE "filename".

Questi preprocessori sono riconosciuti: Altibase APRE*C/C++ (finitura), CASEMaker DBMaker
(dmppc), Firebird/InterBase (gpre), IBM DB2 (db2 precompilare, db2 prep) & Informix
SQL/C (esq), Ingrès (esqlc), Mimero (esq), Oracolo (proc), PostgreSQL (ecc) & IARDA
(yardpc). Se il tuo preprocessore non viene riconosciuto, puoi dire

register-parser oscura_esqlc_preprocessor esql-compilation

Tuttavia, questo gestirà solo lo stile comune a Informix e ad altri: Argomenti di comando
che terminano in ".ec" sono i file da scansionare, "-I" definisce il percorso di inclusione e EXEC SQL
Direttive INCLUDE senza suffisso vengono aggiunti ".h".

sorseggia (sorso)
Swig (involucro semplificato e generatore di interfaccia, http://www.swig.org/) è un programma che
converte un file di intestazione C/C++ nelle funzioni wrapper necessarie per rendere richiamabile il codice
da una varietà di altri linguaggi, come Perl, Python, Tcl, C#, Ruby, OCaml e
probabilmente altri che non conosco.

Makepp comprende e analizza la riga di comando swig, cercando le opzioni "-I" e "-l".
Sa anche come scansionare i file di definizione dell'interfaccia di swig (.i file) cercando
%include, %import e anche "#include" se "-includeall" è attivo.

Se il tuo sorso ha un nome divertente, puoi dire

parser di registro oscura_swig_alias swig

Vera ed Verilog (vcs_compilazione)
Se progetti hardware, questo ti tornerà utile.

Ignorabile involucri (salta parola, guscio)
Makepp riconosce le seguenti parole di comando e molte altre e le salta
opportunamente nella sua ricerca dello scanner corretto: "condor_compile", "distcc",
"ignore_error", "libtool", "noecho" "purify".

Esiste una variante di questo che trova i comandi annidati in "sh -c 'comando1;
comando2'".

Se hai più comandi simili, puoi dire

comando register-parser skip-word

libtool

Libtool è un sistema di compilazione molto intelligente che semplifica notevolmente la condivisione
librerie nascondendo tutti i dettagli dipendenti dal sistema in uno script di shell. Il solo
la difficoltà è che i file binari della libreria non sono effettivamente memorizzati nella stessa directory
come file di output--libtool in realtà crea una sottodirectory, ".libs", che contiene il
file reali. Normalmente questo non è un problema, ma makepp deve sapere dov'è il vero
i binari sono se deve collegarli da un repository. Al momento, le librerie libtool
(file ".la") non sono collegati dai repository; vengono sempre ricostruiti se necessario.
Inoltre, makepp al momento non è in grado di utilizzare le informazioni sulle dipendenze memorizzate
all'interno del file ".la" stesso. Questo si spera cambierà presto.

Soppressione , il scansione (Nessuno)
A volte potresti non voler analizzare una regola o un determinato comando. Puoi spegnere
l'analisi e quindi la scansione con

register-parser cc nessuno

RELATIVA VERSIONI

Scansione veloce ed scansione intelligente
Le opzioni delle regole ":quickscan" e ":smartscan", se applicabili, influiscono sul modo in cui i file
vengono scansionati.

In modalità ":quickscan" (predefinita), tutte le direttive di inclusione sono considerate attive. Questo permette
per una scansione molto efficiente.

In modalità ":smartscan", si tenta di interpretare macro ed espressioni in modo che
le direttive di inclusione inattive vengono ignorate. Ad esempio, l'eseguibile prodotto da
compilare il seguente programma C dovrebbe non dipendere da foo.h:

#se 0
#include "pippo.h"
#endif
int main() { ritorno 0; }

CUSTOM SCANNER

Puoi specificare il tuo parser sia in un'opzione di regola come ":parser foo", sia usando
le istruzioni "register_parser" o "register_command_parser".

Ad ogni modo, come descritto in "register_parser", lì devi direttamente o indirettamente
(tramite una classe) specificare una funzione che crea un oggetto parser. Questo oggetto di solito
creare un oggetto scanner per i file e alimentarlo con i risultati dalla riga di comando
opzioni. Questi due oggetti chiameranno i metodi "add_*_dependency" del parser che
inoltrare le informazioni al "Mpp::Lexer::add_*_dependency" un po' più complicato
funzioni di utilità.

Tuttavia, la tua funzione parser può anche fare questo lavoro per casi semplici. Ci sono
paio di valori restituiti speciali se questa funzione non restituisce un oggetto parser:

"indifeso"
Le informazioni di scansione non sono memorizzabili nella cache e devono essere ricalcolate la prossima volta che la regola è di destinazione
ha bisogno di essere costruito.

"p_none, p_skip_word" o "p_shell"
Queste sono infatti costanti numeriche, che dicono al lexer di fare il lavoro di queste
pseudo-parser.

qualsiasi riferimento, ad esempio "\1"
Ciò equivale a restituire un oggetto parser della base "Mpp::CommandParser"
class, che renderà inoltre il comando eseguibile stesso una dipendenza.

Nella maggior parte dei casi, gli oggetti di tipo "Mpp::CommandParser" dovrebbero istanziare almeno un oggetto
di tipo "Mpp::Scanner". La classe base "Mpp::Scanner" si occupa della distinzione
tra quickscan e smartscan. Si noti che il comportamento di "Mpp::Scanner" può essere notevolmente
interessati da questa distinzione, ma dovrebbe essere trasparente per la classe derivata se lo è
ben formato. Le nuove classi derivate "Mpp::Scanner" dovrebbero essere testate in entrambe le modalità.

Se scrivi la tua classe "Mpp::Scanner", dovresti anche basare la tua decisione sulla nuova scansione
sulle informazioni di build "RESCAN". Questo viene impostato da "makeppreplay" dopo aver firmato i file senza
scansione. Quindi, nonostante le firme siano coerenti, è ancora necessaria una nuova scansione. Se
il tuo "Mpp::Scanner" utilizza il metodo ereditato "scan_file1", probabilmente stai bene.

Per maggiori dettagli, fare riferimento alla documentazione della rispettiva classe. Per esempi, vedere
"Mpp::CommandParser::Gcc" e "Mpp::CommandParser::Vcs". Guarda le funzioni "p_" in
Mpp/Sub.pm che vengono alias nelle rispettive classi come "fabbrica" ​​quando vengono caricati.

Caching scanner info
Se tutti gli effetti collaterali importanti dello scanner vengono effettuati tramite chiamate a metodi
della classe base "Mpp::CommandParser", questi effetti collaterali possono essere memorizzati nella cache nella build
info, in modo che possano essere riprodotti da una successiva invocazione di makepp senza
facendo tutto il costoso lavoro di scansione. Questo può far risparmiare un bel po' di tempo, specialmente in
modalità di scansione intelligente.

Se lo scanner ha altri effetti collaterali importanti, allora dovrebbe chiamare l'oggetto "Regola"
mark_scaninfo_uncacheable metodo. In caso contrario, le informazioni sullo scanner recuperate dalla build
le informazioni potrebbero essere imprecise, causando un errore nel risultato della compilazione. Questo metodo è
chiamato automaticamente quando un valore dall'hash %parser non restituisce un oggetto di tipo
"Mpp::CommandParser", o quando il parser è specificato con un'opzione regola e "p_*"
la routine non restituisce un oggetto di tipo "Mpp::CommandParser".

Le informazioni di scansione memorizzate nella cache vengono invalidate utilizzando criteri simili a quelli utilizzati per determinare quando
l'obiettivo è scaduto. Allo stesso modo, può essere recuperato da un repository usando
criteri simili a quelli utilizzati per determinare quando un obiettivo può essere collegato da a
repository.

Puoi forzare makepp a ignorare le informazioni dello scanner nella cache con l'opzione "--force-rescan".
Ciò è utile quando uno scanner rotto potrebbe aver causato la memorizzazione nella cache di informazioni sullo scanner errate.

Ad Hoc. Scanner
Spesso avrai solo uno o pochi file che contengono informazioni sulle dipendenze. tu no
voglio scriverlo in un makefile in modo ridondante (poiché la ridondanza in seguito spesso porta a
incongruenze quando un aggiornamento viene dimenticato). Ma anche tu non vuoi scrivere a
Mpp::Scanner? Come soluzione alternativa, puoi generare un file di inclusione al volo. Per esempio
Qt ha .qrc file che possono assomigliare a:



abc
xyz
...

Se aderisci al layout di cui sopra, puoi trasformare le linee pertinenti in un makepp
include file, che viene creato automaticamente quando viene incluso.

%.qrc.makepp: %.qrc
&grep 's! \n!$(gambo).cc:! || S! * ! ! && S! \n!!' $(ingresso) -o $(uscita)

include $(carattere jolly *.qrc) # .makepp viene aggiunto automaticamente

Diverse varianti di questo sono date nel Cookbook. Lo svantaggio è che inizi tu
costruzione durante la lettura del makefile. Quindi l'opzione del comando --loop non sarà così utile
alla prima iterazione.

Usa makepp_scanning online utilizzando i servizi onworks.net