Wkrótce system budowania

Przed wydaniem Android 7.0, Android stosowany GNU make wyłącznie do opisania i wykonać swoje zasady budowania. System kompilacji Make jest powszechnie obsługiwany i używany, ale w skali Androida stał się powolny, podatny na błędy, nieskalowalny i trudny do przetestowania. System budowania Soong zapewnia elastyczność wymaganą dla Android buduje.

Z tego powodu oczekuje się, że deweloperzy platform przejdą z Make i zastosują Soong tak szybko, jak to możliwe. Wyślij zapytanie do android budowania Grupy Google, aby otrzymać wsparcie.

Co to jest Wkrótce?

System budowania Soong został wprowadzony w Androidzie 7.0 (nugat), aby zastąpić wykonania. Wykorzystuje się Kati GNU narzędzia Producent klon i Ninja składnik systemu budowania przyspieszenia buduje Androida.

Zobacz Android make build systemu opis w Android Open Source Project (AOSP) do ogólnych instrukcji i zbudować zmian systemowych dla Android.mk Pisarzy , aby dowiedzieć się o zmianach potrzebnych do przystosowania od wprowadzić do Soong.

Zobacz podobne wpisy wbudowany w słowniczku do definicji kluczowych terminów i plików referencyjnych Soong aby uzyskać szczegółowe informacje.

Porównanie marki i wkrótce

Oto porównanie konfiguracji Buduj z Soong realizacji samo w konfiguracji Soong (Blueprint lub .bp ) plików.

Zrób przykład

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)

Niedługo przykład

cc_library_shared {
     name: “libxmlrpc++”,

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

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

Zobacz Prosta konfiguracja kompilacji dla przykładów konfiguracji testowej specyficzne Soong.

Format pliku Android.bp

Zgodnie z projektem, Android.bp pliki są proste. Nie zawierają instrukcji warunkowych ani instrukcji przepływu sterowania; cała złożoność jest obsługiwana przez logikę kompilacji napisaną w Go. Gdy jest to możliwe, składnia i semantyka Android.bp plików są podobne do plików budować Bazel .

Moduły

Moduł W Android.bp startów z plików typu modułu , a następnie przez zestaw właściwości w name: "value", format:

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

Każdy moduł musi mieć name nieruchomość, a wartość musi być unikalna na wszystkich Android.bp plików, z wyjątkiem name wartości nieruchomości w przestrzeniach nazw i modułów gotowych, które mogą się powtarzać.

W srcs określa własności pliki źródłowe wykorzystane do budowy modułu, jako lista ciągów. Można odwołać się do wyjścia z innymi modułami, które produkują pliki źródłowe, jak genrule lub filegroup , używając składni odniesienia modułu ":<module-name>" .

Aby uzyskać listę typów ważny modułowych i ich właściwości, zobacz Soong Moduły Reference .

Rodzaje

Zmienne i właściwości są silnie wpisane, przy czym zmienne są dynamicznie oparte na pierwszym przypisaniu, a właściwości są ustawiane statycznie przez typ modułu. Obsługiwane typy to:

  • Wartości logiczne ( true czy false )
  • Całkowitymi ( int )
  • Struny ( "string" )
  • Wykazy strun ( ["string1", "string2"] )
  • Mapy ( {key1: "value1", key2: ["value2"]} )

Mapy mogą zawierać wartości dowolnego typu, w tym mapy zagnieżdżone. Listy i mapy mogą zawierać końcowe przecinki po ostatniej wartości.

Globy

Właściwości, które przyjmują listę plików, takich jak srcs , mogą również brać wzorce glob. Wzory glob może zawierać normalną UNIX wieloznaczny * , na przykład *.java . Wzory glob może również zawierać pojedynczy ** wieloznaczny jako element ścieżki, która dopasowuje zero lub więcej elementów ścieżki. Na przykład, java/**/*.java pasuje zarówno java/Main.java i java/com/android/Main.java wzory.

Zmienne

Android.bp plik może zawierać przypisania zmiennych najwyższego poziomu:

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

Zmienne są ograniczone do pozostałej części pliku, w którym są zadeklarowane, jak również do wszystkich podrzędnych plików Blueprint. Zmienne są niezmienne z jednym wyjątkiem: mogą być dołączane do z += zadania, ale tylko zanim zostały one odwoływać.

Uwagi

Android.bp pliki mogą zawierać C-styl wielowierszowego /* */ i C ++ stylu jednowierszowym // komentarzy.

Operatorzy

Łańcuchy, listy łańcuchów i mapy mogą być dołączane za pomocą operatora +. Całkowitymi można podsumować pomocą + operatora. Dołączanie mapy tworzy sumę kluczy w obu mapach, dołączając wartości dowolnych kluczy, które są obecne na obu mapach.

Warunkowe

Soong nie obsługuje warunkowe w Android.bp plików. Zamiast tego złożoność reguł kompilacji, która wymagałaby warunków warunkowych, jest obsługiwana w Go, gdzie można używać funkcji języka wysokiego poziomu i można śledzić niejawne zależności wprowadzone przez warunki. Większość warunków warunkowych jest konwertowana na właściwość mapy, w której jedna z wartości na mapie jest wybierana i dołączana do właściwości najwyższego poziomu.

Na przykład, aby obsługiwać pliki specyficzne dla architektury:

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

Formatyzator

Soong obejmuje kanoniczną formatowania plików plan, podobnych do gofmt . Rekursywnie formatowanie wszystkich Android.bp pliki w bieżącym katalogu, uruchom:

bpfmt -w .

Format kanoniczny obejmuje wcięcia z czterema spacjami, nowe wiersze po każdym elemencie listy wieloelementowej oraz końcowy przecinek w listach i mapach.

Moduły specjalne

Niektóre specjalne grupy modułów mają unikalne cechy.

Moduły domyślne

Moduł ustawień domyślnych może służyć do powtarzania tych samych właściwości w wielu modułach. Na przykład:

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

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

Gotowe moduły

Niektóre wstępnie skompilowane typy modułów pozwalają modułowi mieć taką samą nazwę, jak jego odpowiedniki oparte na źródle. Na przykład, nie może być cc_prebuilt_binary nazwie foo , gdy istnieje już cc_binary o tej samej nazwie. Daje to programistom elastyczność w wyborze wersji, którą mają uwzględnić w ich produkcie końcowym. Jeśli konfiguracja build zawiera zarówno wersjach prefer flagę wartość w module Montowane dyktatowi definicję, która wersja ma priorytet. Zauważ, że niektóre moduły prekompilowanych mają nazwy, które nie zaczynają się prebuilt , takie jak android_app_import .

Moduły przestrzeni nazw

Aż zamienia Android w pełni z wnieść do Soong, konfiguracja produktu Producent musi określić PRODUCT_SOONG_NAMESPACES wartość. Jego wartość powinna być lista oddzielonych przestrzeń nazw, że eksport Soong zrobić aby zostać zbudowany przez m polecenia. Po zakończeniu konwersji Androida na Soong szczegóły włączania przestrzeni nazw mogą ulec zmianie.

Soong umożliwia modułom w różnych katalogach określenie tej samej nazwy, o ile każdy moduł jest zadeklarowany w oddzielnej przestrzeni nazw. Przestrzeń nazw można zadeklarować w następujący sposób:

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

Zauważ, że przestrzeń nazw nie ma właściwości name; jego ścieżka jest automatycznie przypisywana jako nazwa.

Każdy moduł Soong ma przypisaną przestrzeń nazw na podstawie jego lokalizacji w drzewie. Każdy moduł Soong jest uważana w przestrzeni nazw zdefiniowanej przez soong_namespace znalezionego w Android.bp pliku w bieżącym katalogu lub katalogu najbliższego przodka. W przypadku braku takiej soong_namespace moduł znajduje się moduł jest uważany w niejawny nazw root.

Oto przykład: Wkrótce próbuje rozwiązać zależność D zadeklarowaną przez moduł M w przestrzeni nazw N, który importuje przestrzenie nazw I1, I2, I3…

  1. Następnie, jeśli D jest w pełni kwalifikowana nazwa formularza //namespace:module , tylko określona przestrzeń nazw jest przeszukiwany przez określony nazwą modułu.
  2. W przeciwnym razie Soong najpierw szuka modułu o nazwie D zadeklarowanego w przestrzeni nazw N.
  3. Jeśli ten moduł nie istnieje, Soong szuka modułu o nazwie D w przestrzeniach nazw I1, I2, I3…
  4. Wreszcie Soong szuka w głównej przestrzeni nazw.