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.

Dlatego deweloperzy platform powinni jak najszybciej przejść z Make na Song. Aby uzyskać pomoc, wyślij pytania do grupy dyskusyjnej Google android-building.

Co to jest Soong?

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

Ogólne instrukcje i zmiany w systemie kompilacji Androida znajdziesz w opisie Android Make Build System w ramach projektu Android Open Source (AOSP). Aby dowiedzieć się, jakie zmiany należy wprowadzić, aby przejść z Make do Soong, zapoznaj się z tymi informacjami.

Definicje kluczowych terminów znajdziesz we wpisach dotyczących kompilacji w słowniku, a szczegółowe informacje znajdziesz w plikach referencyjnych Soong.

Porównanie Make i Soong

Oto porównanie konfiguracji Make z Soong, która osiąga ten sam efekt w pliku konfiguracji Soong (Blueprint 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 utworu

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 do testów znajdziesz w artykule Konfiguracja prostej 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 właściwości.

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 wstępnie utworzone typy modułów umożliwiają nadanie modułowi tej samej nazwy co jego odpowiednikom opartym na źródłach. Na przykład cc_prebuilt_binary może mieć nazwę foo, gdy istnieje już cc_binary o tej samej nazwie. Daje to deweloperom elastyczność w wybieraniu wersji, które mają zostać uwzględnione w ostatecznym 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, np. android_app_import.

Moduły przestrzeni nazw

Dopóki Android nie przejdzie całkowicie na Make na Soong, w konfiguracji produktu Make musisz podać 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 dotyczące włączania przestrzeni nazw mogą się zmienić.

Soong umożliwia modułom w różnych katalogach określanie tej samej nazwy, o ile każdy z nich jest zadeklarowany w osobnej przestrzeni nazw. Przestrzeń nazw można zadeklarować w ten sposób:

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

Pamiętaj, że przestrzeń nazw nie ma właściwości name. 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 znajduje się w przestrzeni nazw zdefiniowanej przez obiekt soong_namespace znajdujący się w pliku Android.bp w bieżącym lub 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 taki moduł nie istnieje, Soong szuka modułu o nazwie D w przestrzeniach nazw I1, I2, I3...
4. Na koniec Soong sprawdza katalog główny.