Format pliku Android.bp

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 lub false)
  • 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.