Система сборки Сунга

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

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

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

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

Смотрите Make сборки Android System описание в рамках проекта Android Open Source (AOSP) для общих инструкций и сборки системных изменений для Android.mk писателей , чтобы узнать о модификации , необходимые для адаптации от Марка к Сун.

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

Сравнение Make и Soong

Вот сравнение конфигурации Make с Сунг выполнения той же в конфигурации Сун (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 файлы просты. Они не содержат условных выражений или операторов потока управления; вся сложность обрабатывается логикой сборки, написанной на Go. Когда это возможно, синтаксис и семантика Android.bp файлов похожи на сборочные файлы БАЗЕЛИ .

Модули

Модуль в 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 модулей Reference .

Типы

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

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

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

Globs

Свойства , которые принимают список файлов, такие как srcs , также могут принимать образцы Глобы. Шаблоны Glob может содержать нормальный UNIX подстановочных * , например *.java . Узоры Glob могут также содержать один ** подстановочных знаков в качестве элемента пути, который соответствует нулю или более элементов пути. Например, 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-стиль многострочного /* */ и стиль C ++ однострочных // комментариев.

Операторы

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

Условные

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

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

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

Форматировщик

Сунг включает в себя каноническую форматировщик для 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 полностью не преобразует Марка в Soong, конфигурации продукта Make необходимо указать PRODUCT_SOONG_NAMESPACES значение. Его значение должно быть разделенными пробелами списка имен, экспорт Сунга сделать , чтобы быть построен m команды. После завершения преобразования Android в Soong детали включения пространств имен могут измениться.

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

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

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

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

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

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