Aree di lavoro, pacchetti e target

Bazel crea software a partire dal codice sorgente organizzato in una struttura ad albero delle directory, chiamata area di lavoro. I file di origine nell'area di lavoro sono organizzati in una gerarchia nidificata di pacchetti, in cui ogni pacchetto è una directory che contiene una serie di file di origine correlati e un file BUILD. Il file BUILD specifica quali output software possono essere creati dal codice sorgente.

Workspace

Un'area di lavoro è una struttura di directory del file system che contiene i file di origine del software che vuoi creare. Ogni area di lavoro ha un file di testo denominato WORKSPACE che potrebbe essere vuoto o può contenere riferimenti a dipendenze esterne necessarie per creare gli output.

Le directory contenenti un file denominato WORKSPACE sono considerate la radice di un'area di lavoro. Pertanto, Bazel ignora qualsiasi albero di directory in uno spazio di lavoro rooted a una sottodirectory contenente un file WORKSPACE, mentre formano un'altra area di lavoro.

Bazel supporta anche un file WORKSPACE.bazel come alias di un file WORKSPACE. Se esistono entrambi i file, viene usato WORKSPACE.bazel.

Repository

Il codice è organizzato in repository. La directory contenente il file WORKSPACE è la radice del repository principale, chiamata anche @. Gli altri repository (esterni) sono definiti nel file WORKSPACE utilizzando le regole dell'area di lavoro.

Le regole delle aree di lavoro integrate in Bazel sono documentate nella sezione Workspace Rules (Regole di Workspace) di Build Encyclopedia e nella documentazione del repository di Starlark incorporato regole.

Poiché i repository esterni sono se stessi, spesso contengono anche un file WORKSPACE. Tuttavia, questi file WORKSPACE aggiuntivi vengono ignorati da Bazel. In particolare, i repository che dipendono dal transito non vengono aggiunti automaticamente.

Pacchetti

L'unità principale dell'organizzazione di codice in un repository è il pacchetto. Un pacchetto è una raccolta di file correlati e una specifica di come utilizzarli per produrre artefatti di output.

Un pacchetto è definito come una directory contenente un file denominato BUILD (o BUILD.bazel). Un pacchetto include tutti i file della directory, più tutte le sottodirectory al suo interno, ad eccezione di quelle che a loro volta contengono un file BUILD. Da questa definizione, nessun file o directory può far parte di due pacchetti diversi.

Ad esempio, nella seguente struttura di directory ci sono due pacchetti my/app e il sottopacchetto my/app/tests. Tieni presente che my/app/data non è un pacchetto, ma una directory che appartiene al pacchetto my/app.

src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc

Destinazioni

Un pacchetto è un contenitore di target che sono definiti nel file BUILD del pacchetto. La maggior parte dei target è di due tipi: file e regole.

I file sono ulteriormente suddivisi in due tipi. I file di origine vengono generalmente scritti dalle risorse degli utenti e registrati nel repository. I file generati, a volte chiamati file derivati o di output, non vengono registrati, ma vengono generati da file di origine.

Il secondo tipo di target viene dichiarato con una regola. Ogni istanza di regola specifica la relazione tra un set di input e un set di file di output. Gli input per una regola possono essere file di origine, ma anche output di altre regole.

Se l'input di una regola è un file di origine o un file generato è nella maggior parte dei casi immateriale. ciò che conta sono solo i contenuti del file, Questo rende più semplice la sostituzione di un file di origine complesso con un file generato da una regola, ad esempio quando l'onere della gestione manuale di un file altamente strutturato diventa troppo noioso e qualcuno scrive un programma per ricavarlo. Non è richiesta alcuna modifica ai consumatori di tale file. Al contrario, un file generato può essere facilmente sostituito da un file di origine con solo modifiche locali.

Gli input in una regola possono includere anche altre regole. Il significato preciso di tali relazioni è spesso piuttosto complesso e dipende dal linguaggio o dalla regola, ma in modo intuitivo è semplice: una regola di libreria C++ A potrebbe avere un'altra regola di libreria C++ B per un input. L'effetto di questa dipendenza è che i file di intestazione di B siano disponibili per A durante la compilazione, i simboli di B sono disponibili per A durante il collegamento e i dati di runtime di B sono disponibili per A durante l'esecuzione.

Una variante di tutte le regole è che i file generati da una regola appartengono sempre allo stesso pacchetto della regola stessa; non è possibile generare file in un altro pacchetto. Non è raro che gli input di una regola provengano da un altro pacchetto.

I gruppi di pacchetti sono insiemi di pacchetti il cui scopo è limitare l'accessibilità di determinate regole. I gruppi di pacchetti sono definiti dalla funzione package_group. Hanno tre proprietà: l'elenco di pacchetti che contengono, il loro nome e altri gruppi di pacchetti che includono. Gli unici modi a cui fare riferimento sono l'attributo visibility delle regole o l'attributo default_visibility della funzione package. non generano o non consumano file. Per ulteriori informazioni, consulta la documentazione di package_group.

Etichette