Файлы Android.bp
по своей сути просты. Они не содержат условных операторов и операторов управления потоком выполнения; вся сложность решается логикой сборки, написанной на Go.
Модули
Модуль в файле 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>"
.
Список допустимых типов модулей и их свойств см. в Справочнике модулей Сунга .
Типы
Переменные и свойства строго типизированы: переменные динамически определяются первым присвоением, а свойства устанавливаются статически, согласно типу модуля. Поддерживаются следующие типы:
- Булевы значения (
true
илиfalse
) - Целые числа (
int
) - Строки (
"string"
) - Списки строк (
["string1", "string2"]
) - Карты (
{key1: "value1", key2: ["value2"]}
)
Карты могут содержать значения любого типа, включая вложенные карты. Списки и карты могут содержать запятые после последнего значения.
Глобсы
Свойства, принимающие список файлов, например srcs
, также могут принимать шаблоны glob. Шаблоны 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++.
Операторы
Строки, списки строк и карты можно добавлять с помощью оператора +. Целые числа можно суммировать с помощью оператора +
. Добавление карты приводит к объединению ключей обеих карт, добавляя значения всех ключей, присутствующих в обеих картах.
Модули по умолчанию
Разработчики могут использовать модуль 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"],
}
Обратите внимание, что пространство имен не имеет свойства name
; его путь автоматически назначается в качестве имени.
Каждому модулю Soong назначается пространство имён в зависимости от его расположения в дереве. Считается, что каждый модуль Soong находится в пространстве имён, определяемом параметром soong_namespace
, найденным в файле Android.bp
в текущем каталоге или ближайшем родительском каталоге. Если такой модуль soong_namespace
не найден, модуль считается находящимся в неявном корневом пространстве имён.
Вот пример: Сунг пытается разрешить зависимость D, объявленную модулем M в пространстве имен N, которое импортирует пространства имен I1, I2, I3…
- Тогда, если D — это полное имя в форме
//namespace:module
, поиск указанного имени модуля выполняется только в указанном пространстве имен. - В противном случае Soong сначала ищет модуль с именем D, объявленный в пространстве имен N.
- Если этот модуль не существует, Soong ищет модуль с именем D в пространствах имен I1, I2, I3…
- Сунг ищет в корневом пространстве имен.
Условные предложения
Soong не поддерживает условные операторы в файлах Android.bp
. Вместо этого, сложные правила сборки, требующие условных операторов, обрабатываются в Go, где можно использовать высокоуровневые функции языка и отслеживать неявные зависимости, создаваемые условными операторами. Большинство условных операторов преобразуются в свойство карты, где одно из значений карты выбирается и добавляется к свойствам верхнего уровня.
Например, для поддержки файлов, специфичных для архитектуры:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Форматировщик
Soong включает канонический форматировщик для файлов Blueprint, аналогичный gofmt . Чтобы рекурсивно переформатировать все файлы Android.bp
в текущем каталоге, выполните:
bpfmt -w .
Канонический формат включает отступы в четыре пробела, новые строки после каждого элемента многоэлементного списка и завершающую запятую в списках и картах.