Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Soong Build System

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

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

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

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

См. Описание Android Make Build System в Android Open Source Project (AOSP) для получения общих инструкций и Изменений сборки системы для Android.mk Writers, чтобы узнать об изменениях, необходимых для адаптации от 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 дизайну файлы Android.bp просты. Они не содержат условных выражений или операторов потока управления; вся сложность обрабатывается логикой сборки, написанной на Go. По возможности синтаксис и семантика файлов Android.bp аналогичны файлам Bazel BUILD .

Модули

Модуль в файле Android.bp начинается с типа модуля, за которым следует набор свойств в name: "value", формат:

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

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

Свойство srcs указывает исходные файлы, используемые для сборки модуля, в виде списка строк. Вы можете ссылаться на выводе других модулей , которые производят исходные файлы, как genrule или filegroup , используя синтаксис ссылки модуля ":<module-name>" .

Список допустимых типов модулей и их свойств см. В справочнике Soong Modules .

Типы

Переменные и свойства строго типизированы, переменные динамически основаны на первом присваивании, а свойства статически устанавливаются типом модуля. Поддерживаемые типы:

  • Booleans ( true или false )
  • Целые числа ( int )
  • Строки ( "string" )
  • Списки строк ( ["string1", "string2"] )
  • Карты ( {key1: "value1", key2: ["value2"]} )

Карты могут содержать значения любого типа, включая вложенные карты. Списки и карты могут иметь запятые после последнего значения.

Globs

Свойства, которые принимают список файлов, такие как srcs , также могут принимать шаблоны srcs . Шаблоны глобуса могут содержать обычный подстановочный знак UNIX * , например *.java . Шаблоны глобуса также могут содержать один ** подстановочный знак в качестве элемента пути, который соответствует нулю или большему количеству элементов пути. Например, java/**/*.java соответствует java/Main.java и java/com/android/Main.java .

переменные

Файл Android.bp может содержать назначения переменных верхнего уровня:

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

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

Комментарии

Файлы Android.bp могут содержать многострочные /* */ и однострочные комментарии в стиле C /* */ // .

операторы

Строки, списки строк и карты могут быть добавлены с помощью оператора +. Целые числа можно суммировать с помощью оператора + . Добавление карты создает объединение ключей на обеих картах, добавляя значения любых ключей, присутствующих на обеих картах.

Conditionals

Soong не поддерживает условия в файлах Android.bp . Вместо этого, сложность в правилах сборки, которая требует условных выражений, обрабатывается в Go, где могут использоваться высокоуровневые языковые функции и неявные зависимости, вводимые условными обозначениями. Большинство условий преобразуются в свойство карты, где одно из значений на карте выбирается и добавляется к свойствам верхнего уровня.

Например, для поддержки файлов, специфичных для архитектуры:

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

Formatter

Soong включает канонический форматер для файлов Blueprint, аналогичный gofmt . Чтобы рекурсивно переформатировать все файлы Android.bp в текущем каталоге, выполните:

 bpfmt -w .
 

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

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

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

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

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

 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"],
}
 

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

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

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

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