Diese Seite wurde von der Cloud Translation API übersetzt.

Soong Build-System

Vor der Android Version 7.0, verwendet Android GNU Make ausschließlich zu beschreiben und führen ihre Build - Regeln. Das Make-Build-System wird weithin unterstützt und verwendet, aber im Umfang von Android wurde es langsam, fehleranfällig, nicht skalierbar und schwer zu testen. Das Soong Build - System bietet die Flexibilität , die für Android aufbaut.

Aus diesem Grund wird von Plattformentwicklern erwartet, dass sie so schnell wie möglich von Make wechseln und Soong übernehmen. Bitte senden Sie Fragen zu der Android-Aufbau Google - Gruppe Unterstützung zu erhalten.

Was ist Soong?

Das Soong Build - System wurde in Android 7.0 (Nougat) eingeführt Fabrikat zu ersetzen. Es nutzt die Kati GNU Make Klonwerkzeug und Ninja - Build - System - Komponente Builds von Android zu beschleunigen.

Sehen Sie sich die Android Make - Build - System Beschreibung im Android Open Source Project (AOSP) für allgemeine Anweisungen und Build - Systemänderungen für Android.mk Writers über Änderungen lernen müssen von Make zu Soong anzupassen.

Siehe die Build-bezogenen Einträge im Glossar für Definitionen von Schlüsselbegriffen und die Soong Referenzdateien für alle Details.

Make-and-Soong-Vergleich

Hier ist ein Vergleich von Make - Konfiguration mit Soong das gleiche in einer Soong - Konfiguration (Blueprint oder das Erledigen .bp ) Datei.

Mach 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)

Bald Beispiel

cc_library_shared {
     name: “libxmlrpc++”,

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

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

Siehe Einfache Build - Konfiguration für testspezifischen Soong Konfigurationsbeispiele.

Android.bp-Dateiformat

Durch Design, Android.bp sind Dateien einfach. Sie enthalten keine Bedingungen oder Kontrollflussanweisungen; die gesamte Komplexität wird durch in Go geschriebene Build-Logik gehandhabt. Wenn möglich, die Syntax und Semantik von Android.bp sind Dateien , ähnlich wie Bazel BUILD - Dateien .

Module

Ein Modul in einer Android.bp Datei beginnt mit einem Modultyp , gefolgt von einer Reihe von Eigenschaften in 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 srcs Eigenschaft gibt die Quelldateien verwendet , um das Modul zu bauen, als eine Liste von Strings. Sie können die Ausgabe anderer Module verweisen , die Quelldateien erzeugen, wie genrule oder filegroup , indem Sie das Modul Referenz - Syntax ":<module-name>" .

Eine Liste der gültigen Modultypen und deren Eigenschaften finden Sie in der Soong - Module Referenz .

Typen

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

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

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

Kugeln

Eigenschaften , die eine Liste von Dateien nehmen, wie srcs können auch glob Muster nehmen. Glob - Muster können die normale UNIX Platzhalter enthalten * , zum Beispiel *.java . Glob - Muster können auch ein einzelnes enthalten ** Wildcard als Pfadelement, das entspricht null oder mehr Pfadelemente. Zum Beispiel java/**/*.java passt sowohl die java/Main.java und java/com/android/Main.java Muster.

Variablen

Eine Android.bp Datei kann auf oberster Ebene Variablenzuweisungen enthalten:

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

Variablen gelten für den Rest der Datei, in der sie deklariert sind, sowie für alle untergeordneten Blueprint-Dateien. Variablen sind mit einer Ausnahme unveränderlich: sie können mit einem bis angefügt += Zuweisung, aber nur , bevor sie verwiesen worden sind.

Kommentare

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

Betreiber

Strings, Stringlisten und Maps können mit dem Operator + angehängt werden. Ganze Zahlen können bis mit dem summiert + Operator. Das Anhängen einer Map erzeugt die Vereinigung der Schlüssel in beiden Maps, indem die Werte aller Schlüssel angehängt werden, die in beiden Maps vorhanden sind.

Bedingungen

Soong nicht unterstützt conditionals in Android.bp Dateien. Stattdessen wird die Komplexität von Buildregeln, die Bedingungen erfordern würden, in Go behandelt, wo High-Level-Sprachfeatures 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, bei der einer der Werte in der Karte ausgewählt und an die Eigenschaften der obersten Ebene angehängt wird.

Um beispielsweise architekturspezifische Dateien zu unterstützen:

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

Formatierer

Soong enthält eine kanonische Formatierer für Blueprint - Dateien, ähnlich wie gofmt . Rekursiv umformatieren alle Android.bp Dateien im aktuellen Verzeichnis, führen:

bpfmt -w .

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

Sondermodule

Einige spezielle Modulgruppen haben einzigartige Eigenschaften.

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 haben wie seine quellbasierten Gegenstücke. Zum Beispiel kann es sein , cc_prebuilt_binary namens foo , wenn es bereits cc_binary mit dem gleichen Namen. Dies gibt Entwicklern die Flexibilität zu wählen, welche Version sie in ihr Endprodukt aufnehmen möchten. Wenn eine Build - Konfiguration beiden Versionen enthält, die es prefer , Flag - Wert in der vorgebauten Moduldefinition diktiert , welche Version Priorität hat. Beachten Sie, dass einige vorgefertigte Module Namen haben , die mit nicht starten prebuilt , wie android_app_import .

Namespace-Module

Bis Android voll von Make zu Soong umwandelt, muss die Make Produktkonfiguration einen angeben PRODUCT_SOONG_NAMESPACES Wert. Sein Wert sollte eine durch Leerzeichen getrennte Liste von Namensräumen sein , dass Soong Exporte durch den eingebauten machen zu m - Befehl. 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, solange jedes Modul in einem separaten Namespace deklariert wird. Ein Namespace kann wie folgt deklariert werden:

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

Beachten Sie, dass ein Namespace keine name-Eigenschaft besitzt; sein Pfad wird automatisch als Name zugewiesen.

Jedem Soong-Modul wird basierend auf seiner Position im Baum ein Namespace zugewiesen. Jede Soong - Modul wird als im Namensraum durch dem definiert sein soong_namespace in einer gefundenen Android.bp Datei im aktuellen Verzeichnis oder am nächsten Vorfahren Verzeichnis. Wenn keine solche soong_namespace Modul gefunden wird, wird das Modul in der impliziten Stammnamespace angesehen werden.

Hier ist ein Beispiel: Soong versucht, die von Modul M deklarierte Abhängigkeit D im Namensraum N aufzulösen, der die Namensräume I1, I2, I3 importiert…

Dann , wenn D ein vollständig qualifizierter Name des Formular ist //namespace:module , nur der angegebene Namespace wird für die angegebenen Modulnamen gesucht.
Andernfalls sucht Soong zuerst nach einem Modul namens D, das im Namensraum N deklariert ist.
Wenn dieses Modul nicht existiert, sucht Soong nach einem Modul namens D in den Namensräumen I1, I2, I3…
Schließlich sucht Soong im Root-Namespace.