In base alla progettazione, i file Android.bp
sono semplici. Non contengono condizionali o istruzioni di flusso di controllo; tutta la complessità è gestita dalla logica di creazione scritta in Go. Quando possibile, la sintassi e la semantica dei file Android.bp
sono simili ai file Bazel BUILD .
Moduli
Un modulo in un file Android.bp
inizia con un tipo di modulo seguito da un insieme di proprietà nel name: "value",
formato:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Ogni modulo deve avere una proprietà name
e il valore deve essere univoco in tutti i file Android.bp
, ad eccezione dei valori della proprietà name
negli spazi dei nomi e nei moduli predefiniti, che potrebbero ripetersi.
La proprietà srcs
specifica i file sorgente utilizzati per creare il modulo, come un elenco di stringhe. Puoi fare riferimento all'output di altri moduli che producono file sorgente, come genrule
o filegroup
, utilizzando la sintassi di riferimento del modulo ":<module-name>"
.
Per un elenco dei tipi di moduli validi e delle relative proprietà, consultare la Guida di riferimento dei moduli Soong .
Tipi
Le variabili e le proprietà sono fortemente tipizzate, con variabili basate dinamicamente sulla prima assegnazione e proprietà impostate staticamente dal tipo di modulo. I tipi supportati sono:
- Booleani (
true
ofalse
) - Numeri interi (
int
) - Stringhe (
"string"
) - Elenchi di stringhe (
["string1", "string2"]
) - Mappe (
{key1: "value1", key2: ["value2"]}
Le mappe possono contenere valori di qualsiasi tipo, comprese le mappe nidificate. Elenchi e mappe possono contenere virgole finali dopo l'ultimo valore.
Globi
Le proprietà che accettano un elenco di file, come srcs
, possono anche accettare modelli glob. I modelli globali possono contenere il normale carattere jolly UNIX *
, ad esempio *.java
. I modelli globali possono anche contenere un singolo carattere jolly **
come elemento del percorso, che corrisponde a zero o più elementi del percorso. Ad esempio, java/**/*.java
corrisponde sia ai modelli java/Main.java
che java/com/android/Main.java
.
Variabili
Un file Android.bp
può contenere assegnazioni di variabili di primo livello:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
L'ambito delle variabili è il resto del file in cui sono dichiarate, nonché qualsiasi file Blueprint figlio. Le variabili sono immutabili con un'eccezione: possono essere aggiunte con un'assegnazione +=
, ma solo prima che venga fatto riferimento.
Commenti
//
file Android.bp
possono contenere commenti /* */
a riga singola in stile C e // a riga singola in stile C++.
Operatori
Stringhe, elenchi di stringhe e mappe possono essere aggiunti utilizzando l'operatore +. Gli interi possono essere sommati utilizzando l'operatore +
. L'aggiunta di una mappa produce l'unione delle chiavi in entrambe le mappe, aggiungendo i valori di tutte le chiavi presenti in entrambe le mappe.
Condizionali
Soong non supporta i condizionali nei file Android.bp
. Invece, la complessità delle regole di compilazione che richiederebbero condizionali viene gestita in Go, dove è possibile utilizzare funzionalità del linguaggio di alto livello e tenere traccia delle dipendenze implicite introdotte dai condizionali. La maggior parte dei condizionali viene convertita in una proprietà della mappa, in cui uno dei valori nella mappa viene selezionato e aggiunto alle proprietà di livello superiore.
Ad esempio, per supportare file specifici dell'architettura:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Formattatore
Soong include un formattatore canonico per i file Blueprint, simile a gofmt . Per riformattare in modo ricorsivo tutti i file Android.bp
nella directory corrente, esegui:
bpfmt -w .
Il formato canonico include rientri di quattro spazi, nuove righe dopo ogni elemento di un elenco multielemento e una virgola finale negli elenchi e nelle mappe.