Конвертировать из Make в Soong

До выпуска Android 7.0 Android использовал GNU Make исключительно для описания и выполнения своих правил сборки. Система сборки Make широко поддерживается и используется, но в масштабах Android стала медленной, подверженной ошибкам, немасштабируемой и сложной для тестирования. Система сборки Soong обеспечивает гибкость, необходимую для сборок Android.

По этой причине разработчики платформы должны как можно скорее перейти от Make к Soong. Отправляйте вопросы в группу Google по созданию Android , чтобы получить поддержку.

Что такое Сунг?

Система сборки Soong была введена в Android 7.0 (Nougat) для замены Make. Она использует инструмент клонирования Kati GNU Make и компонент системы сборки Ninja для ускорения сборки Android.

Общие инструкции см. в описании системы сборки Android Make в проекте Android Open Source Project (AOSP), а сведения об изменениях в системе сборки для разработчиков Android.mk см. в разделе «Изменения в системе сборки для разработчиков Android.mk», чтобы узнать об изменениях, необходимых для адаптации Make к Soong.

Определения ключевых терминов см. в записях глоссария, посвященных сборке , а полную информацию можно найти в справочных файлах Soong .

Сравнение Мейка и Сунга

Ниже приведено сравнение конфигурации Make с Soong, выполняющим тот же самый результат в файле конфигурации Soong (Blueprint или .bp ).

Покажите пример 

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)

Пример Сонга 

cc_library_shared {
     name: "libxmlrpc++",

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

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

Примеры конфигурации Soong для конкретных тестов см. в разделе Простая конфигурация сборки .

Объяснение полей в файле Android.bp см. в разделе Формат файла Android.bp .

Специальные модули

Некоторые специальные группы модулей имеют уникальные характеристики.

Модули по умолчанию

Модуль defaults может использоваться для повторения одних и тех же свойств в нескольких модулях. Например:

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

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

Готовые модули

Некоторые типы предварительно собранных модулей позволяют модулю иметь то же имя, что и его аналоги на основе исходного кода. Например, может быть cc_prebuilt_binary с именем foo , когда уже есть cc_binary с тем же именем. Это дает разработчикам гибкость в выборе версии для включения в конечный продукт. Если конфигурация сборки содержит обе версии, значение флага prefer в определении предварительно собранного модуля определяет, какая версия имеет приоритет. Обратите внимание, что некоторые предварительно собранные модули имеют имена, которые не начинаются с prebuilt , например android_app_import .

Модули пространства имен

Пока Android полностью не преобразуется из Make в Soong, конфигурация продукта Make должна указывать значение PRODUCT_SOONG_NAMESPACES . Его значение должно быть списком пространств имен, разделенных пробелами, которые Soong экспортирует в Make для сборки командой m . После завершения преобразования Android в Soong детали включения пространств имен могут измениться.

Soong предоставляет возможность модулям в разных каталогах указывать одно и то же имя, если каждый модуль объявлен в отдельном пространстве имен. Пространство имен может быть объявлено следующим образом:

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

Обратите внимание, что пространство имен не имеет свойства имени; его путь автоматически назначается в качестве имени.

Каждому модулю Soong назначается пространство имен на основе его расположения в дереве. Каждый модуль Soong считается находящимся в пространстве имен, определенном soong_namespace , найденным в файле Android.bp в текущем каталоге или ближайшем родительском каталоге. Если такой модуль soong_namespace не найден, модуль считается находящимся в неявном корневом пространстве имен.

Вот пример: Сунг пытается разрешить зависимость D, объявленную модулем M в пространстве имен N, которое импортирует пространства имен I1, I2, I3…

  1. Тогда, если D — это полное имя в форме //namespace:module , поиск указанного имени модуля выполняется только в указанном пространстве имен.
  2. В противном случае Soong сначала ищет модуль с именем D, объявленный в пространстве имен N.
  3. Если этот модуль не существует, Soong ищет модуль с именем D в пространствах имен I1, I2, I3…
  4. Наконец, Сунг просматривает корневое пространство имен.