Google 致力于为黑人社区推动种族平等。查看具体举措。
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Soong Build System

Vor der Veröffentlichung von Android 7.0 verwendete Android GNU Make ausschließlich zur Beschreibung und Ausführung seiner Build-Regeln. Das Make-Build-System wird weitgehend unterstützt und verwendet, wurde jedoch im Android-Maßstab langsam, fehleranfällig, nicht skalierbar und schwer zu testen. Das Soong-Build-System bietet die für Android-Builds erforderliche Flexibilität.

Aus diesem Grund wird von Plattformentwicklern erwartet, dass sie so schnell wie möglich von Make wechseln und Soong übernehmen. Senden Sie Fragen an die Google-Gruppe, die Android erstellt , um Unterstützung zu erhalten.

Was ist Soong?

Das Soong-Build-System wurde in Android 7.0 (Nougat) eingeführt, um Make zu ersetzen. Es nutzt das Kati GNU Make-Klon-Tool und die Ninja- Build-Systemkomponente, um Builds von Android zu beschleunigen.

In der Beschreibung zu Android Make Build System im Android Open Source Project (AOSP) finden Sie allgemeine Anweisungen und Änderungen am Build System für Android.mk Writers. Dort erfahren Sie, welche Änderungen für die Anpassung von Make an Soong erforderlich sind.

Ausführliche Informationen finden Sie in den Build-bezogenen Einträgen im Glossar für Definitionen der Schlüsselbegriffe und in den Soong-Referenzdateien .

Make and Soong Vergleich

Hier ist ein Vergleich von Make configuration mit Soong, der dasselbe in einer Soong-Konfigurationsdatei (Blueprint oder .bp ) erreicht.

Machen Sie ein Beispiel

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux

LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src

LOCAL_SRC_FILES := $(call \
     all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)

Soong Beispiel

cc_library_shared {
     name: “libxmlrpc++”,

     rtti: true,
     cppflags: [
           “-Wall”,
           “-Werror”,
           “-fexceptions”,
     ],
     export_include_dirs: [“src”],
     srcs: [“src/**/*.cpp”],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

Testspezifische Soong-Konfigurationsbeispiele finden Sie unter Einfache Build -Konfiguration.

Android.bp Dateiformat

Android.bp Dateien sind von Android.bp einfach. Sie enthalten keine Bedingungen oder Kontrollflussanweisungen. Die gesamte Komplexität wird durch die in Go geschriebene Build-Logik behandelt. Wenn möglich, ähneln die Syntax und Semantik von Android.bp Dateien denen von Bazel BUILD-Dateien .

Module

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

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

Jedes Modul muss einen haben name - Eigenschaft und der Wert muss für alle eindeutig sein Android.bp Dateien, mit Ausnahme der name Eigenschaftswerte in Namensräumen und vorgefertigte Module, die wiederholen kann.

Die Eigenschaft srcs gibt die zum Erstellen des Moduls verwendeten Quelldateien als Liste von Zeichenfolgen an. Sie können auf die Ausgabe anderer Module genrule , die Quelldateien wie genrule oder filegroup , indem Sie die filegroup ":<module-name>" filegroup ":<module-name>" .

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

Typen

Variablen und Eigenschaften sind stark typisiert, wobei Variablen dynamisch auf der ersten Zuweisung basieren und Eigenschaften statisch vom Modultyp festgelegt werden. Die unterstützten Typen sind:

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

Karten können Werte beliebigen Typs enthalten, einschließlich verschachtelter Karten. Listen und Karten können nach dem letzten Wert nachgestellte Kommas enthalten.

Globs

Eigenschaften, die eine Liste von Dateien enthalten, z. B. srcs , können auch Glob-Muster annehmen. Glob-Muster können den normalen UNIX-Platzhalter * , z. B. *.java . Glob-Muster können auch einen einzelnen ** Platzhalter als Pfadelement enthalten, der null oder mehr Pfadelementen entspricht. Beispielsweise entspricht java/**/*.java sowohl den Mustern java/Main.java als auch java/com/android/Main.java .

Variablen

Eine Android.bp Datei kann Variablenzuweisungen der obersten 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 beschränkt, in der sie deklariert sind, sowie auf alle untergeordneten Blueprint-Dateien. Variablen sind mit einer Ausnahme unveränderlich: Sie können mit einer += Zuweisung angehängt werden, jedoch nur, bevor sie referenziert wurden.

Bemerkungen

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

Betreiber

Zeichenfolgen, Listen von Zeichenfolgen und Karten können mit dem Operator + angehängt werden. Ganzzahlen können mit dem Operator + werden. Durch das Anhängen einer Karte wird die Vereinigung von Schlüsseln in beiden Karten erzeugt, wobei die Werte aller Schlüssel angehängt werden, die in beiden Karten vorhanden sind.

Bedingungen

Soong unterstützt keine Bedingungen in Android.bp Dateien. Stattdessen wird die Komplexität von Erstellungsregeln, die Bedingungen erfordern würden, in Go behandelt, wo Sprachfunktionen auf hoher Ebene verwendet werden können und implizite Abhängigkeiten, die durch Bedingungen eingeführt werden, verfolgt werden können. Die meisten Bedingungen werden in eine Karteneigenschaft konvertiert, in der einer der Werte in der Karte ausgewählt und an die Eigenschaften der obersten Ebene angehängt wird.

So unterstützen Sie beispielsweise architekturspezifische 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 . Android.bp alle Android.bp Dateien im aktuellen Verzeichnis rekursiv neu zu formatieren:

bpfmt -w .

Das kanonische Format enthält Einrückungen mit vier Leerzeichen, neue Zeilen nach jedem Element einer Multielement-Liste und ein nachfolgendes Komma in Listen und Karten.

Spezielle Module

Einige spezielle Modulgruppen weisen einzigartige Eigenschaften auf.

Standardmodule

Ein Standardmodul kann verwendet werden, um dieselben Eigenschaften in mehreren Modulen zu wiederholen. Zum Beispiel:

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

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

Vorgefertigte Module

Bei einigen vorgefertigten Modultypen kann ein Modul denselben Namen wie seine quellenbasierten Gegenstücke haben. Beispielsweise kann es eine cc_prebuilt_binary Namen foo wenn bereits eine cc_binary mit demselben Namen vorhanden ist. Dies gibt Entwicklern die Flexibilität zu wählen, welche Version in ihr Endprodukt aufgenommen werden soll. Wenn eine Build-Konfiguration beide Versionen enthält, bestimmt der Wert für das prefer Flag in der vorgefertigten Moduldefinition, welche Version Priorität hat. Beachten Sie, dass einige vorgefertigte Module Namen haben, die nicht mit prebuilt , wie z. B. android_app_import .

Namespace-Module

Bis Android vollständig von Make nach Soong konvertiert, muss in der Make-Produktkonfiguration ein PRODUCT_SOONG_NAMESPACES Wert angegeben werden. Sein Wert sollte eine durch Leerzeichen getrennte Liste von Namespaces sein, die Soong nach Make exportiert, um sie mit dem Befehl m zu erstellen. Nachdem die Konvertierung von Android zu Soong abgeschlossen ist, können sich die Details zum Aktivieren von Namespaces ändern.

Soong bietet Modulen in verschiedenen Verzeichnissen die Möglichkeit, denselben Namen anzugeben, sofern jedes Modul in einem separaten Namespace deklariert ist. Ein Namespace kann folgendermaßen deklariert werden:

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

Beachten Sie, dass ein Namespace keine Namenseigenschaft hat. Sein Pfad wird automatisch als Name zugewiesen.

Jedem Soong-Modul wird basierend auf seiner Position im Baum ein Namespace zugewiesen. Jedes Soong-Modul befindet sich in dem Namespace, der durch den soong_namespace definiert ist, der in einer Android.bp Datei im aktuellen Verzeichnis oder im nächstgelegenen Vorfahrenverzeichnis enthalten ist. Wenn kein solches soong_namespace Modul gefunden wird, wird das Modul als im impliziten Root-Namespace befindlich betrachtet.

Hier ein Beispiel: Soong versucht, die vom Modul M deklarierte Abhängigkeit D im Namespace N aufzulösen, der die Namespaces I1, I2, I3 importiert.

  1. Wenn D ein vollständig qualifizierter Name des Formulars //namespace:module , wird nur der angegebene Namespace nach dem angegebenen Modulnamen durchsucht.
  2. Andernfalls sucht Soong zuerst nach einem Modul namens D, das im Namespace N deklariert ist.
  3. Wenn dieses Modul nicht existiert, sucht Soong in den Namespaces I1, I2, I3… nach einem Modul mit dem Namen D.
  4. Zuletzt schaut Soong in den Root-Namespace.