Pliki Android.bp
są proste z założenia. Nie zawierają one instrukcji warunkowych ani instrukcji sterowania przepływem danych. Całą złożoność obsługuje logika kompilacji napisana w języku Go. W miarę możliwości składnia i semantyka plików Android.bp
są podobne do plików BUILD w Bazel.
Moduły
Moduł w pliku Android.bp
zaczyna się od typu modułu, a następuje po nim zestaw właściwości w formacie name: "value",
:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Każdy moduł musi mieć właściwość name
, a jej wartość musi być unikalna we wszystkich plikach Android.bp
, z wyjątkiem wartości właściwości name
w przestrzeniach nazw i w gotowych modułach, które mogą się powtarzać.
Właściwość srcs
określa pliki źródłowe użyte do skompilowania modułu jako lista ciągów znaków. Za pomocą składni odwołania do modułu ":<module-name>"
możesz odwoływać się do danych wyjściowych innych modułów, które tworzą pliki źródłowe, np. genrule
lub filegroup
.
Listę prawidłowych typów modułów i ich właściwości znajdziesz w dokumentacji modułów Song.
Typy
Zmienne i właściwości mają ściśle określony typ. Zmienne są dynamicznie przypisywane do pierwszego przypisania, a właściwości są ustawiane statycznie przez typ modułu. Obsługiwane typy:
- Wartości logiczne (
true
lubfalse
) - Liczby całkowite (
int
) - Ciągi znaków (
"string"
) - Listy ciągów tekstowych (
["string1", "string2"]
) - Mapy (
{key1: "value1", key2: ["value2"]}
)
Mapy mogą zawierać wartości dowolnego typu, w tym zagnieżdżone mapy. Listy i mapy mogą mieć przecinki po ostatniej wartości.
Globy
Właściwości, które przyjmują listę plików, np. srcs
, mogą też przyjmować wzorce globów. Wzorce glob mogą zawierać zwykły symbol wieloznaczny UNIX *
, na przykład *.java
. Wzorce globów mogą też zawierać jeden symbol wieloznaczny **
jako element ścieżki, który pasuje do co najmniej jednego elementu ścieżki. Na przykład wyrażenie java/**/*.java
pasuje do wzorca java/Main.java
i do wzorca java/com/android/Main.java
.
Zmienne
Plik Android.bp
może zawierać przypisania zmiennych na najwyższym poziomie:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
Zmienne są ograniczone do reszty pliku, w którym zostały zadeklarowane, a także do wszystkich podrzędnych plików Blueprint. Zmienne są niezmienne z jednym wyjątkiem: można do nich dołączać przypisania za pomocą instrukcji +=
, ale tylko przed ich wywołaniem.
Komentarze
Pliki Android.bp
mogą zawierać komentarze wielowierszowe w stylu C (/* */
) oraz jednowierszowe w stylu C++ (//
).
Operatorzy
Ciągi tekstowe, listy ciągów tekstowych i mapy można dołączać za pomocą operatora +.
Liczba całkowita może być sumowana za pomocą operatora +
. Dołączanie mapy powoduje złączenie kluczy z obu map i dodanie wartości wszystkich kluczy, które występują w obu mapach.
Warunki
Soong nie obsługuje warunków w plikach Android.bp
. Zamiast tego złożoność reguł kompilacji, które wymagają instrukcji warunkowych, jest obsługiwana w języku Go, gdzie można używać funkcji języka na wysokim poziomie, a ukryte zależności wprowadzone przez instrukcje warunkowe można śledzić. Większość warunków jest konwertowana na właściwości mapy, w których wybierana jest jedna z wartości mapy i dodawana do właściwości najwyższego poziomu.
Na przykład, aby obsługiwać pliki dla konkretnej architektury:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Formatowanie
Soong zawiera kanoniczny formater plików Blueprint, podobny do gofmt. Aby rekurencyjnie przeformatować wszystkie pliki Android.bp
w bieżącym katalogu, uruchom:
bpfmt -w .
Format kanoniczny obejmuje wcięcia co 4 spacje, nowe wiersze po każdym elemencie listy wieloelementowej oraz przecinek na końcu w listach i mapach.