Формат файла Android.bp

По своей сути файлы 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>" .

Список допустимых типов модулей и их свойств см. в справочнике модулей Soong, созданном при выполнении команды m soong_docs . Результат будет находиться в out/soong/docs/soong_build.html .

Типы

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

  • Логические значения ( 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 не найден, модуль считается находящимся в неявном корневом пространстве имен.

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

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

Условные

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

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

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

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

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

bpfmt -w .

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