Pliki Android.bp
są projektowane z myślą o prostym. 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 w przypadku wszystkich plików Android.bp
, z wyjątkiem wartości właściwości name
w przestrzeni nazw i wstępnie utworzonych 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 są wpisane dynamicznie, a zmienne zależą od typu w pierwszej kolejności, a także z właściwościami ustawionymi statycznie według typu modułu. obsługiwane typy to:
- 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ą zawierać przecinki po ostatniej wartości.
Kule
Właściwości, które przyjmują listę plików, np. srcs
, mogą też przyjmować wzorce globów. Wzorce glob mogą zawierać normalny symbol wieloznaczny UNIX *
, na przykład *.java
. Wzorce kuli ziemskiej mogą też zawierać pojedynczy symbol wieloznaczny **
jako ścieżkę
, który pasuje do 0 lub więcej elementów ś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 najwyższego poziomu:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
Zmienne są ograniczone do pozostałej części pliku, w którym zostały zadeklarowane.
jak dowolne podrzędne pliki planów. Zmiennej nie można zmienić z jednym wyjątkiem:
można dołączyć do projektu +=
, ale tylko przed
wymienionych.
Komentarze
Pliki Android.bp
mogą zawierać komentarze wielowierszowe w stylu C (/* */
) oraz jednowierszowe w stylu C++ (//
).
Operatorzy
Za pomocą operatora + można dołączać ciągi znaków, listy ciągów znaków i mapy.
Całkowite można sumować za pomocą operatora +
. Dołączenie mapy powoduje wygenerowanie
sumy kluczy w obu mapach, z dołączeniem wartości wszystkich kluczy znajdujących się w
obie te mapy.
Warunki
Utwór nie obsługuje warunków warunkowych 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"],
},
},
}
Narzędzie formatujące
Soong zawiera kanoniczny formater plików Blueprint, podobny do gofmt. Aby cyklicznie zmieniać format wszystkich elementów
Liczba plików w bieżącym katalogu: Android.bp
, 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.