Android.bp dosyaları, tasarım gereği basittir. Koşullu ifadeler veya kontrol akışı ifadeleri içermezler. Tüm karmaşıklık, Go ile yazılmış derleme mantığı tarafından işlenir.
Modüller
Bir Android.bp dosyasındaki modül, name: "value", biçiminde bir özellikler grubuyla birlikte modül türü ile başlar:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Her modülde bir name özelliği olmalıdır ve değer, ad alanlarındaki ve önceden oluşturulmuş modüllerdeki name özelliği değerleri hariç tüm Android.bp dosyalarında benzersiz olmalıdır. Bu değerler tekrar edebilir.
srcs özelliği, modülü oluşturmak için kullanılan kaynak dosyaları bir dize listesi olarak belirtir. genrule veya filegroup gibi kaynak dosyalar oluşturan diğer modüllerin çıkışına, ":<module-name>" modül referansı söz dizimini kullanarak başvurabilirsiniz.
Geçerli modül türlerinin ve özelliklerinin listesi için Soong Modules Reference (Soong Modülleri Referansı) başlıklı makaleyi inceleyin.
Türler
Değişkenler ve özellikler kesin olarak türlenir. Değişkenler, ilk atamaya göre dinamik olarak belirlenir. Özellikler ise modül türüne göre statik olarak ayarlanır. Desteklenen türler şunlardır:
- Boole değerleri (
trueveyafalse) - Tam sayılar (
int) - Dizeler (
"string") - Dize listeleri (
["string1", "string2"]) - Haritalar (
{key1: "value1", key2: ["value2"]})
Haritalar, iç içe yerleştirilmiş haritalar da dahil olmak üzere herhangi bir türde değer içerebilir. Listelerde ve haritalarda son değerden sonra virgül olabilir.
Globs
srcs gibi dosya listesi alan özellikler, glob desenlerini de alabilir. Glob kalıpları, normal UNIX joker karakteri *'yı içerebilir. Örneğin, *.java. Glob kalıpları, sıfır veya daha fazla yol öğesiyle eşleşen bir yol öğesi olarak tek bir ** joker karakter de içerebilir. Örneğin, java/**/*.java hem java/Main.java hem de java/com/android/Main.java kalıplarıyla eşleşir.
Değişkenler
Bir Android.bp dosyası, üst düzey değişken atamaları içerebilir:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
Değişkenler, bildirildikleri dosyanın geri kalanı ve tüm alt Blueprint dosyalarıyla sınırlıdır. Değişkenler bir istisna dışında değişmezdir: += atamasıyla eklenebilirler ancak yalnızca referans verilmeden önce.
Yorumlar
Android.bp dosyaları, C tarzı çok satırlı /* */ ve C++ tarzı tek satırlı // yorumlar içerebilir.
Operatörler
Dizeler, dize listeleri ve haritalar + operatörü kullanılarak eklenebilir.
Tam sayılar, + operatörü kullanılarak toplanabilir. Bir harita eklemek, her iki haritadaki anahtarların birleşimini oluşturur ve her iki haritada da bulunan anahtarların değerlerini ekler.
Varsayılan modüller
Geliştiriciler, aynı özellikleri birden fazla modülde tekrarlamak için bir varsayılanlar modülü kullanabilir. Örneğin:
cc_defaults {
name: "gzip_defaults",
shared_libs: ["libz"],
stl: "none",
}
cc_binary {
name: "gzip",
defaults: ["gzip_defaults"],
srcs: ["src/test/minigzip.c"],
}
Önceden oluşturulmuş modüller
Bazı önceden oluşturulmuş modül türleri, bir modülün kaynak tabanlı benzerleriyle aynı ada sahip olmasına olanak tanır. Örneğin, aynı ada sahip bir cc_binary zaten varken cc_prebuilt_binary adlı bir foo olabilir. Bu sayede geliştiriciler, son ürünlerine hangi sürümü dahil edeceklerini seçme esnekliğine sahip olur. Bir derleme yapılandırması her iki sürümü de içeriyorsa önceden oluşturulmuş modül tanımındaki prefer işareti değeri, hangi sürümün öncelikli olduğunu belirler.
Bazı hazır modüllerin adlarının prebuilt ile başlamadığını (ör. android_app_import) unutmayın.
Ad alanı modülleri
Android, Make'ten Soong'a tamamen geçene kadar Make ürün yapılandırmasında PRODUCT_SOONG_NAMESPACES değeri belirtilmelidir. Değeri, Soong'un m komutuyla oluşturulmak üzere Make'e aktardığı, boşlukla ayrılmış ad alanları listesi olmalıdır. Android'in Soong'a dönüştürülmesi tamamlandıktan sonra ad alanlarının etkinleştirilmesiyle ilgili ayrıntılar değişebilir.
Soong, her modül ayrı bir ad alanında bildirildiği sürece farklı dizinlerdeki modüllerin aynı adı belirtmesine olanak tanır. Geliştiriciler bir ad alanı bildirebilir:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
Ad alanının name özelliği olmadığını unutmayın. Ad alanı yolu, adı olarak otomatik şekilde atanır.
Her Soong modülüne, ağaçtaki konumuna göre bir ad alanı atanır.
Her Soong modülü, geçerli dizindeki veya en yakın üst dizindeki bir Android.bp dosyasında bulunan soong_namespace tarafından tanımlanan ad alanında kabul edilir. Böyle bir soong_namespace modülü bulunamazsa modülün örtülü kök ad alanında olduğu kabul edilir.
Örneğin: Soong, ad alanı N'de I1, I2, I3… ad alanlarını içe aktaran M modülü tarafından bildirilen D bağımlılığını çözmeye çalışıyor.
- Ardından, D,
//namespace:modulebiçiminde tam olarak nitelendirilmiş bir adsa belirtilen modül adı için yalnızca belirtilen ad alanı aranır. - Aksi takdirde Soong, önce N ad alanında tanımlanan D adlı bir modülü arar.
- Bu modül yoksa Soong, I1, I2, I3 ad alanlarında D adlı bir modül arar.
- Soong, kök ad alanına bakar.
Koşullu ifadeler
Soong, Android.bp dosyalarındaki koşulları desteklemez. Bunun yerine, koşullu ifadeler gerektiren derleme kurallarındaki karmaşıklık, üst düzey dil özelliklerinin kullanılabildiği ve koşullu ifadelerden kaynaklanan örtülü bağımlılıkların izlenebildiği Go'da ele alınır. Çoğu koşullu ifade, haritadaki değerlerden birinin seçilip üst düzey özelliklere eklendiği bir harita özelliğine dönüştürülür.
Örneğin, mimariye özel dosyaları desteklemek için:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Biçimlendirici
Soong, gofmt'ye benzer şekilde Blueprint dosyaları için standart bir biçimlendirici içerir. Geçerli dizindeki tüm Android.bp dosyalarını yinelemeli olarak yeniden biçimlendirmek için şunu çalıştırın:
bpfmt -w .
Standart biçimde dört boşlukluk girintiler, çok öğeli bir listedeki her öğeden sonra yeni satırlar ve listelerde ve haritalarda sondaki virgül bulunur.