Android.bp-Dateiformat

Android.bp-Dateien sind von Natur aus einfach. Sie enthalten keine bedingten Anweisungen oder Kontrollflussanweisungen. Die gesamte Komplexität wird durch die in Go geschriebene Build-Logik verarbeitet.

Module

Ein Modul in einer Android.bp-Datei beginnt mit einem Modultyp, gefolgt von einer Reihe von Attributen im name: "value",-Format:

cc_binary {
    name: "gzip",
    srcs: ["src/test/minigzip.c"],
    shared_libs: ["libz"],
    stl: "none",
}

Jedes Modul muss ein name-Attribut haben und der Wert muss in allen Android.bp-Dateien eindeutig sein. Ausnahmen sind die name-Attributwerte in Namespaces und vorgefertigten Modulen, die sich wiederholen dürfen.

Mit der Eigenschaft srcs werden die Quelldateien angegeben, die zum Erstellen des Moduls verwendet werden. Sie wird als Liste von Strings angegeben. Sie können mit der Modulreferenzsyntax ":<module-name>" auf die Ausgabe anderer Module verweisen, die Quelldateien wie genrule oder filegroup erzeugen.

Eine Liste der gültigen Modultypen und ihrer Eigenschaften finden Sie in der Soong-Modulreferenz.

Typen

Variablen und Attribute sind stark typisiert. Variablen werden dynamisch auf Grundlage der ersten Zuweisung festgelegt und Attribute statisch nach Modultyp. Folgende Typen werden unterstützt:

  • Boolesche Werte (true oder false)
  • Ganzzahlen (int)
  • Strings ("string")
  • Listen mit Strings (["string1", "string2"])
  • Karten ({key1: "value1", key2: ["value2"]})

Maps können Werte beliebigen Typs enthalten, einschließlich verschachtelter Maps. Listen und Maps können nach dem letzten Wert ein nachgestelltes Komma haben.

Globs

Für Properties, die eine Liste von Dateien akzeptieren, z. B. srcs, können auch Glob-Muster verwendet werden. Glob-Muster können den normalen UNIX-Platzhalter * enthalten, z. B. *.java. Glob-Muster können auch einen einzelnen Platzhalter ** als Pfadelement enthalten, der null oder mehr Pfadelementen entspricht. Beispiel: java/**/*.java entspricht sowohl dem Muster java/Main.java als auch dem Muster java/com/android/Main.java.

Variablen

Eine Android.bp-Datei kann Zuweisungen von Variablen auf oberster Ebene enthalten:

gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
    name: "gzip",
    srcs: gzip_srcs,
    shared_libs: ["libz"],
    stl: "none",
}

Variablen sind auf den Rest der Datei, in der sie deklariert sind, sowie auf alle untergeordneten Blueprint-Dateien beschränkt. Variablen sind unveränderlich, mit einer Ausnahme: Sie können mit einer +=-Zuweisung ergänzt werden, aber nur bevor auf sie verwiesen wurde.

Kommentare

Android.bp-Dateien können mehrzeilige Kommentare im C-Stil /* */ und einzeilige Kommentare im C++-Stil // enthalten.

Netzbetreiber

Zeichenfolgen, Listen von Zeichenfolgen und Maps können mit dem Operator „+“ angehängt werden. Ganzzahlen können mit dem Operator + addiert werden. Beim Anhängen einer Map wird die Vereinigung der Schlüssel in beiden Maps erstellt und die Werte aller Schlüssel angehängt, die in beiden Maps vorhanden sind.

Standardmodule

Entwickler können ein Standardmodul verwenden, um dieselben Attribute in mehreren Modulen zu wiederholen. Beispiel:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

Vordefinierte Module

Bei einigen vordefinierten Modultypen kann ein Modul denselben Namen wie seine quellbasierten Gegenstücke haben. So kann es beispielsweise ein cc_prebuilt_binary mit dem Namen foo geben, wenn bereits ein cc_binary mit demselben Namen vorhanden ist. So können Entwickler flexibel auswählen, welche Version sie in ihr Endprodukt aufnehmen möchten. Wenn eine Build-Konfiguration beide Versionen enthält, bestimmt der prefer-Flag-Wert in der Definition des vorgefertigten Moduls, welche Version Priorität hat. Einige vorgefertigte Module haben Namen, die nicht mit prebuilt beginnen, z. B. android_app_import.

Namespace-Module

Bis Android vollständig von Make zu Soong migriert ist, muss in der Make-Produktkonfiguration ein PRODUCT_SOONG_NAMESPACES-Wert angegeben werden. Der Wert sollte eine durch Leerzeichen getrennte Liste von Namespaces sein, die Soong für Make exportiert, damit sie mit dem Befehl m erstellt werden können. Nach der Umstellung von Android auf Soong können sich die Details zum Aktivieren von Namespaces ändern.

Soong bietet die Möglichkeit, dass Module in verschiedenen Verzeichnissen denselben Namen angeben, sofern jedes Modul in einem separaten Namespace deklariert wird. Entwickler können einen Namespace deklarieren:

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

Ein Namespace hat keine name-Eigenschaft. Sein Pfad wird automatisch als Name zugewiesen.

Jedem Soong-Modul wird basierend auf seinem Speicherort im Baum ein Namespace zugewiesen. Jedes Soong-Modul befindet sich im Namespace, der durch die soong_namespace in einer Android.bp-Datei im aktuellen Verzeichnis oder im nächstgelegenen übergeordneten Verzeichnis definiert wird. Wenn kein solches soong_namespace-Modul gefunden wird, wird davon ausgegangen, dass sich das Modul im impliziten Stamm-Namespace befindet.

Beispiel: Soong versucht, die von Modul M im Namespace N deklarierte Abhängigkeit D aufzulösen, wobei die Namespaces I1, I2, I3… importiert werden.

  1. Wenn D ein voll qualifizierter Name der Form //namespace:module ist, wird nur im angegebenen Namespace nach dem angegebenen Modulnamen gesucht.
  2. Andernfalls sucht Soong zuerst nach einem Modul mit dem Namen „D“, das im Namespace „N“ deklariert ist.
  3. Wenn dieses Modul nicht vorhanden ist, sucht Soong nach einem Modul mit dem Namen „D“ in den Namespaces I1, I2, I3…
  4. Soong sucht im Root-Namespace.

Bedingungen

Soong unterstützt keine Bedingungen in Android.bp-Dateien. Stattdessen wird die Komplexität in Build-Regeln, die bedingte Anweisungen erfordern, in Go behandelt. Dort können High-Level-Sprachfunktionen verwendet und implizite Abhängigkeiten, die durch bedingte Anweisungen eingeführt werden, nachverfolgt werden. Die meisten Bedingungen werden in eine Karten-Eigenschaft konvertiert, wobei einer der Werte in der Karte ausgewählt und an die Eigenschaften der obersten Ebene angehängt wird.

Beispiel: So unterstützen Sie architekturabhängige Dateien:

cc_library {
    ...
    srcs: ["generic.cpp"],
    arch: {
        arm: {
            srcs: ["arm.cpp"],
        },
        x86: {
            srcs: ["x86.cpp"],
        },
    },
}

Formatierer

Soong enthält einen kanonischen Formatierer für Blueprint-Dateien, ähnlich wie gofmt. Führen Sie Folgendes aus, um alle Android.bp-Dateien im aktuellen Verzeichnis rekursiv neu zu formatieren:

bpfmt -w .

Das kanonische Format umfasst Einrückungen mit vier Leerzeichen, neue Zeilen nach jedem Element einer Liste mit mehreren Elementen und ein nachgestelltes Komma in Listen und Maps.