Konwertowanie z Make na Soong

Przed wydaniem Androida 7.0 system Android używał wyłącznie GNU Make do opisania i wykonania swoich reguł kompilacji. System kompilacji Make jest szeroko obsługiwany i używany, ale w przypadku Androida stał się powolny, podatny na błędy, nierozwijalny i trudny do przetestowania. System kompilacji Song zapewnia elastyczność wymaganą w przypadku kompilacji na Androida.

Z tego powodu oczekuje się, że deweloperzy platform jak najszybciej odejdą od tworzenia i wdrażania funkcji. Aby uzyskać pomoc, prześlij pytania do grupy Google android-building.

Co to jest Soong?

System kompilacji Soong został wprowadzony w Androidzie 7.0 (Nougat), aby zastąpić Markę. Używa ona narzędzia do klonowania Kati GNU Make i komponentu systemu kompilacji Ninja, aby przyspieszyć kompilację Androida.

Zapoznaj się z opisem Android Make Build System w projekcie Android Open Source Project (AOSP) zawierającym ogólne instrukcje i artykuł na temat tworzenia zmian w systemie Android.mk Writers, aby dowiedzieć się więcej o zmianach, które trzeba wprowadzić, aby przejść z programu Make do Soong.

Definicje kluczowych terminów znajdziesz w artykule o kompilacji w glosariuszu, a pełne informacje – w plikach referencyjnych Songa.

Porównanie Make i Soong

Oto porównanie konfiguracji tworzenia z narzędziem Soong, które daje taki sam efekt w pliku konfiguracji Soong (planu lub .bp).

Tworzenie przykładu

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)

Przykład Soong

cc_library_shared {
     name: "libxmlrpc++",

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

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

Przykłady konfiguracji Soong w przypadku testów znajdziesz w sekcji Prosta konfiguracja kompilacji.

Objaśnienia pól w pliku Android.bp znajdziesz w sekcji Format pliku Android.bp.

Moduły specjalne

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

Moduły domyślne

Moduł domyślny może służyć do powtarzania tych samych właściwości w różnych 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 gotowe typy modułów mogą mieć taką samą nazwę jak jego odpowiedniki oparte na źródle. Na przykład może istnieć element cc_prebuilt_binary o nazwie foo, gdy istnieje już obiekt cc_binary o tej samej nazwie. Zapewnia to deweloperom swobodę wyboru wersji, która ma zostać użyta w produkcie. Jeśli konfiguracja kompilacji zawiera obie wersje, wartość flagi prefer w definicji gotowego modułu wskazuje, która wersja ma priorytet. Pamiętaj, że niektóre gotowe moduły mają nazwy, które nie zaczynają się od prebuilt, na przykład android_app_import.

Moduły przestrzeni nazw

Dopóki Android nie dokona pełnej konwersji z Maker na Soong, konfiguracja tworzenia produktu musi określać wartość PRODUCT_SOONG_NAMESPACES. Jego wartość powinna być rozdzieloną spacjami listą przestrzeni nazw, które Soong eksportuje do Make, aby zostały skompilowane przez polecenie m. Po zakończeniu konwersji Androida na Soong szczegóły włączania przestrzeni nazw mogą ulec zmianie.

Soong umożliwia modułom znajdującym się w różnych katalogach określenie tej samej nazwy, o ile każdy moduł jest zadeklarowany w osobnej przestrzeni nazw. Przestrzeń nazw może być zadeklarowana w ten sposób:

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

Zwróć uwagę, że przestrzeń nazw nie ma właściwości „name”, a jej ścieżka jest automatycznie przypisywana jako nazwa.

Każdy moduł Soong ma przypisaną przestrzeń nazw na podstawie swojej lokalizacji w drzewie. Każdy moduł Soong jest uważany za znajdujący się w przestrzeni nazw zdefiniowanej przez soong_namespace znaleziony w pliku Android.bp w bieżącym katalogu lub w najbliższym katalogu nadrzędnym. W przypadku braku takiego modułu soong_namespace jest on uważany za znajdujący się w niejawnej głównej przestrzeni nazw.

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

1. Jeśli D jest pełną nazwą w formie //namespace:module, tylko w określonym zakresie nazw szuka się określonego modułu.
2. W przeciwnym razie Soong najpierw szuka modułu o nazwie D zadeklarowanego w przestrzeni nazw N.
3. Jeśli moduł nie istnieje, Soong szuka modułu o nazwie D w przestrzeniach nazw I1, I2, I3 itd.
4. Soong sprawdza się w głównej przestrzeni nazw.