Questo modulo fornisce la classe di base astratta per la classe CCompiler. Un'istanza CCompiler può essere usata per tutti i passaggi di compilazione e link necessari per compilare un singolo progetto. I metodi vengono forniti per impostare le opzioni del compilatore -- definizioni di macro, include delle directory, percorsi di link, librerie ed il resto.
Questo modulo fornisce le seguenti funzioni:
compiler, library_dirs, runtime_library_dirs, libraries) |
macros, include_dirs) |
osname, platform) |
osname dovrebbe essere uno dei nomi standard di Python per i vari OS (per esempio uno fra quelli restituiti da os.name e platform, il valore comune restituito da sys.platform per la piattaforma in questione.
Il valore predefinito è os.name
e sys.platform
nel caso
in cui i parametri non vengano indicati.
plat=None , compiler=None , verbose=0 , dry_run=0 , force=0 ) |
os.name
(per esempio
'posix'
, 'nt'
e compiler predefiniti sono i
predefiniti per quella piattaforma. Attualmente solo 'posix'
e
'nt'
sono supportati ed i compilatori predefiniti hanno
``l'interfaccia tradizionale Unix`` (classe UnixCCompiler)
e visual C++(classe MSVCCompiler). Si noti che è possibile
chiedere che un compilatore Unix generi oggetti sotto Windows e che
un compilatore Microsoft compili oggetti sotto Unix--se si fornisce
un valore per compiler, plat viene ignorato.
) |
build
,
build_ext
, build_clib
).
[verbose=0 , dry_run=0 , force=0 ]) |
La classe astratta di base CCompiler definisce l'interfaccia che deve essere implementata da una classe compiler reale. La classe ha a disposizione anche alcuni metodi utili usati da diverse classi compiler.
L'idea di base dietro una classe di astrazione del compilatore è che ogni istanza può essere usata per tutti i passaggi di compilazione/link nella preparazione di un singolo progetto. Quindi, attributi comuni a tutti questi passaggi di compilazione e link -- incluse directory, macro da definire, librerie da linkare assieme, etc. -- sono attributi dell'istanza compiler. Per permettere la variabilità nel trattamento individuale di file, molti di questi attributi possono essere variati nella fase di precompilazione o pre-link.
Il costruttore per ogni sottoclasse crea un'istanza dell'oggetto
Compiler. Ha a disposizione le seguenti opzioni verbose (mostra
un output dettagliato), dry_run (non vengono eseguiti tutti i
passaggi) e force (ricompila ogni cosa, indipendentemente dalle
dipendenze). Tutte queste opzioni sono, in modo predefinito,
impostate a 0
(off). Si noti che probabilmente non si vuole
istanziare direttamente CCompiler o una delle sue sottoclassi
- si usi piuttosto la funzione integrata
distutils.CCompiler.new_compiler().
I seguenti metodi permettono di alterare manualmente le opzioni del compilatore per l'istanza della classe Compiler.
dir) |
dirs) |
libname) |
Aggiunge libname alla lista delle librerie che verranno incluse in tutti i link guidati da questo oggetto compiler. Si noti che libname *non* dovrebbe essere il nome del file contenente la libreria, ma il nome della libreria stessa: il nome del file attuale verrà desunto dal linker, dal compilatore o dalla classe compiler (in funzione della piattaforma).
Il linker verrà istruito a linkare nuovamente le librerie nell'ordine in cui vengono fornite a add_library() e/o set_libraries(). È consentito duplicare i nomi di liberia; il linker verrà istruito a linkare nuovamente le librerie tante volte quante sono quelle menzionate.
libnames) |
dir) |
dirs) |
dir) |
dirs) |
name[, value=None ]) |
name) |
object) |
objects) |
I seguenti metodi implementano metodi per l'auto individuazione delle opzioni del compilatore, fornendo alcune funzionalità simili all'autoconf della GNU.
sources) |
dirs, lib[, debug=0 ]) |
None
se
lib non viene trovata in nessuna delle directory specificate.
funcname [, includes=None , include_dirs=None , libraries=None , library_dirs=None ]) |
dir) |
lib) |
dir) |
**args) |
attributo | descrizione |
---|---|
Il compilatore C/C++ | |
linker usato per creare oggetti e librerie condivise | |
linker usato per creare binari eseguibili | |
creatore di libreria statico |
Sulle piattaforme con una riga di comando (Unix, DOS/Windows), ognuna di queste è una stringa che verrà suddivisa nel nome dell'eseguibile e (facoltativamente) una lista di argomenti. La suddivisione della stringa viene effettuata in modo similare a come la shell Unix lavora: le parole vengono delimitate da spazi, ma virgolette e backslash possono sovrascriverle. Si veda distutils.util.split_quoted().
I seguenti metodi invocano le diverse fasi del processo di compilazione.
sources[, output_dir=None , macros=None , include_dirs=None , debug=0 , extra_preargs=None , extra_postargs=None , depends=None ]) |
sources deve essere una lista di nomi di file, più esattamente file C/C++, ma in realtà ogni cosa che può essere gestita da un particolare compilatore e da una particolare classe Compiler (per esempio la MSVCCompiler può gestire file di risorse in sources). Restituisce una lista di nomi di oggetti file, uno per ogni nome di file sorgente presente in sources. A seconda dell'implementazione, non tutti i file sorgenti verranno necessariamente compilati, ma tutti i corrispondenti nomi di oggetti file verranno restituiti.
Se output_dir viene indicata, gli oggetti file vi saranno inseriti, mantenendo comunque il loro componente relativo al percorso originale. Quindi foo/bar.c normalmente si compila in foo/bar.o (per una implementazione Unix); se output_dir è build, verrà quindi compilato in build/foo/bar.o.
macros, se indicata, deve essere una lista di definizioni di
macro. Una definizione di macro è sia una tupla-doppia
(name, value) che singola (name,). Il primo definisce una
macro; se il valore è None
, la macro viene definita senza un
esplicito valore. Il caso della singola tupla non-definisce una
macro. Successive definizioni/ridefinizioni/non-definizioni
acquisiscono la precedenza.
include_dirs, se indicato, deve essere una lista di stringhe, le directory da aggiungere ai percorsi di ricerca standard per gli include, solamente in questa compilazione.
debug è booleano; se vero, il compilatore verrà informato di fornire in uscita i simboli di debug nell'oggetto/i file.
extra_preargs e extra_postargs sono implementazioni dipendenti. Sulle piattaforme che possiedono la notazione da riga di comando (per esempio Unix, DOS/Windows), sono più semplicemente liste di stringhe: argomenti da riga di comando extra da aggiungere alla riga di comando del compilatore. Per le altre piattaforme, si consulti la documentazione dell'implementazione della classe. In ogni caso, vengono intese come una scappatoia per quelle occasioni in cui l'ambiente astratto del compilatore non rispetta le aspettative.
depends, se indicato, è una lista di nomi di file da cui tutti gli obiettivi dipendono. Se un file sorgente è più vecchio di ogni file nelle dipendenze, il file sorgente non verrà ricompilato. Questo supporta il tracciamento delle dipendenze, ma solo ad un livello di granularità grossolana.
Solleva l'eccezione CompileError in caso di fallimento.
objects, output_libname[, output_dir=None , debug=0 , target_lang=None ]) |
output_libname dovrebbe essere un nome di libreria, non un nome di file; il nome del file verrà dedotto dal nome della libreria. output_dir è la directory dove il file di libreria verrà inserito.
debug è un tipo booleano; se vero, le informazioni di debugging verranno incluse nella libreria (si noti che su diverse piattaforme, è nel passaggio della compilazione che questo avviene: l'opzione debug qui viene inclusa solamente per coerenza).
target_lang è il linguaggio di destinazione per cui l'oggetto indicato viene compilato. Questo permette uno specifico trattamento durante la fase di linking per alcuni linguaggi.
Solleva l'eccezione LibError in caso di errore.
target_desc, objects, output_filename[, output_dir=None , libraries=None , library_dirs=None , runtime_library_dirs=None , export_symbols=None , debug=0 , extra_preargs=None , extra_postargs=None , build_temp=None , target_lang=None ]) |
Il concetto di ``bunch of stuff'' è composto da una lista di oggetti file forniti come objects. output_filename dovrebbe essere un nome di file. Se output_dir viene fornito, output_filename è a lui relativo (per esempio output_filename può fornire componenti di directory se necessario).
libraries è una lista di librerie da linkare assieme. Queste sono nomi di librerie, non nomi di file, dal momento che questi vengono tradotti in nomi di file nella modalità specifica della piattaforma (per esempio foo diventa libfoo.a in Unix e foo.lib in DOS/Windows). Comunque, possono includere un componente di directory, che dice al linker di cercare in quella specifica directory anziché cercare in tutti i soliti posti.
library_dirs, se indicate, dovrebbero essere una lista di directory dove cercare le librerie che sono state specificate come nomi di libreria semplice (per esempio nessun componente di directory). Queste si trovano all'inizio del sistema predefinito e forniscono quanto richiesto a add_library_dir() e/o set_library_dirs(). runtime_library_dirs è una lista di directory che verranno inserite all'interno della libreria condivisa ed usate per cercare altre librerie condivise da cui *queste* dipendono durante l'esecuzione. (Questo è rilevante solo su Unix).
export_symbols è una lista di simboli che le librerie condivise esporteranno. (Questo è rilevante solo su Windows.)
debug è come per compile() e create_static_lib(), con una piccola distinzione che attualmente riguarda la maggior parte delle piattaforme (al contrario di create3_static_lib(), che include un'opzione debug principalmente per la propria configurazione).
extra_preargs e extra_postargs sono come per compile() (eccetto per il fatto che abitualmente forniscono argomenti da riga di comando per il particolare linker da usare).
target_lang è il linguaggio di destinazione per cui l'oggetto indicato viene compilato. Questo permette un trattamento specifico durante il linking per particolari linguaggi.
Solleva l'eccezione LinkError in caso di errore.
objects, output_progname[, output_dir=None , libraries=None , library_dirs=None , runtime_library_dirs=None , debug=0 , extra_preargs=None , extra_postargs=None , target_lang=None ]) |
objects, output_libname[, output_dir=None , libraries=None , library_dirs=None , runtime_library_dirs=None , export_symbols=None , debug=0 , extra_preargs=None , extra_postargs=None , build_temp=None , target_lang=None ]) |
objects, output_filename[, output_dir=None , libraries=None , library_dirs=None , runtime_library_dirs=None , export_symbols=None , debug=0 , extra_preargs=None , extra_postargs=None , build_temp=None , target_lang=None ]) |
source[, output_file=None , macros=None , include_dirs=None , extra_preargs=None , extra_postargs=None ]) |
Solleva l'eccezione PreprocessError in caso di errore.
I seguenti comodi metodi vengono definiti dalla classe CCompiler, per essere usati da diverse concrete sottoclassi.
basename[, strip_dir=0 , output_dir='' ]) |
libname[, lib_type='static' , strip_dir=0 , output_dir='' ]) |
'static'
tipicamente sarà nella
forma di liblibname.a, quando con lib_type di
tipo 'dynamic'
sarà nella forma di liblibname.so.
source_filenames[, strip_dir=0 , output_dir='' ]) |
basename[, strip_dir=0 , output_dir='' ]) |
func, args[, msg=None , level=1 ]) |
cmd) |
name[, mode=511 ]) |
src, dst) |
msg[, level=1 ]) |
msg) |
msg) |
Vedete Circa questo documento... per informazioni su modifiche e suggerimenti.