Android 7.0 sürümünden önce Android, derleme kurallarını açıklamak ve yürütmek için özel olarak GNU Make'ı kullanıyordu. Make derleme sistemi yaygın olarak destekleniyor ve kullanılıyor, ancak Android ölçeğinde yavaş, hataya açık, ölçeklenemez ve test edilmesi zor hale geldi. Soong derleme sistemi , Android derlemeleri için gereken esnekliği sağlar.
Bu nedenle platform geliştiricilerinin en kısa sürede Make and benimsemek Soong'dan geçiş yapması bekleniyor. Destek almak için android oluşturan Google Grubuna sorular gönderin.
Soong nedir?
Soong yapı sistemi , Make'ın yerini almak üzere Android 7.0'da (Nougat) tanıtıldı. Android derlemelerini hızlandırmak için Kati GNU Make klon aracını ve Ninja yapı sistemi bileşenini kullanır.
Genel talimatlar için Android Açık Kaynak Projesi'ndeki (AOSP) Android Make Build System açıklamasına ve Make'dan Soong'a uyarlamak için gereken değişiklikleri öğrenmek için Android.mk Yazarları için Sistem Değişiklikleri Oluştur'a bakın.
Anahtar terimlerin tanımları için sözlükteki yapıyla ilgili girişlere ve tüm ayrıntılar için Soong referans dosyalarına bakın.
Yap ve Yakında karşılaştırması
Burada, Make konfigürasyonu ile Soong'un aynı şeyi bir Soong konfigürasyon (Blueprint veya .bp ) dosyasında gerçekleştirmesinin bir karşılaştırması bulunmaktadır.
Örnek ol
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux
LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src
LOCAL_SRC_FILES := $(call \
all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)
Yakında örnek
cc_library_shared {
name: “libxmlrpc++”,
rtti: true,
cppflags: [
“-Wall”,
“-Werror”,
“-fexceptions”,
],
export_include_dirs: [“src”],
srcs: [“src/**/*.cpp”],
target: {
darwin: {
enabled: false,
},
},
}
Teste özel Soong yapılandırma örnekleri için Basit Yapı Yapılandırmasına bakın.
Android.bp dosya biçimi
Tasarım gereği, Android.bp dosyaları basittir. Koşullar veya kontrol akışı deyimleri içermezler; tüm karmaşıklık, Go'da yazılmış yapı mantığıyla ele alınır. Mümkün olduğunda, Android.bp dosyalarının sözdizimi ve semantiği Bazel BUILD dosyalarına benzer.
Modüller
Android.bp dosyasındaki bir modül, bir modül türü ile başlar ve ardından name: "value", bir dizi özellik gelir:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Her modülün bir name özelliğine sahip olması gerekir ve ad alanlarındaki name özelliği değerleri ve önceden oluşturulmuş modüller dışında tekrarlanabilecek değer tüm Android.bp dosyalarında benzersiz olmalıdır.
srcs özelliği, modülü oluşturmak için kullanılan kaynak dosyalarını bir dize listesi olarak belirtir. ":<module-name>" modül başvuru sözdizimini kullanarak, genrule veya filegroup gibi kaynak dosyaları üreten diğer modüllerin çıktılarına başvurabilirsiniz.
Geçerli modül türlerinin ve özelliklerinin bir listesi için Soong Modülleri Referansına bakın.
Türler
Değişkenler ve özellikler, ilk atamaya göre dinamik olarak değişkenler ve modül tipi tarafından statik olarak ayarlanan özellikler ile kesin olarak yazılır. Desteklenen türler şunlardır:
- Boolean (
trueveyafalse) - Tamsayılar (
int) - Dizeler (
"string") - Dize listeleri (
["string1", "string2"]) - Haritalar (
{key1: "value1", key2: ["value2"]})
Haritalar, iç içe geçmiş haritalar da dahil olmak üzere herhangi bir türden değer içerebilir. Listeler ve haritalar, son değerden sonra virgül içerebilir.
Küreler
srcs gibi bir dosya listesi alan özellikler de glob desenleri alabilir. Glob desenleri normal UNIX joker karakterini * içerebilir, örneğin *.java . Glob desenleri, yol öğesi olarak sıfır veya daha fazla yol öğesiyle eşleşen 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şkenlerin kapsamı, içinde bildirildikleri dosyanın geri kalanının yanı sıra herhangi bir alt Blueprint dosyasına göre belirlenir. Değişkenler bir istisna dışında değişmezdir: bir += atamasıyla eklenebilirler, ancak yalnızca başvurulmadan önce.
Yorumlar
Android.bp dosyaları, C stili çok satırlı /* */ ve C++ stili tek satırlı // yorumları içerebilir.
operatörler
Diziler, dizi listeleri ve haritalar + operatörü kullanılarak eklenebilir. Tam sayılar + operatörü kullanılarak toplanabilir. Bir harita eklemek, her iki haritada da bulunan anahtarların değerlerini ekleyerek her iki haritada da anahtar birleşimini üretir.
Şartlılar
Soong, Android.bp dosyalarında koşul ifadelerini desteklemez. Bunun yerine, yüksek seviyeli dil özelliklerinin kullanılabileceği ve koşul tarafından getirilen örtük bağımlılıkların izlenebileceği, koşullandırma gerektiren yapı kurallarındaki karmaşıklık Go'da ele alınır. Çoğu koşul, haritadaki değerlerden birinin seçildiği ve üst düzey özelliklere eklendiği bir harita özelliğine dönüştürülür.
Örneğin, mimariye özgü dosyaları desteklemek için:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
biçimlendirici
Soong, Blueprint dosyaları için gofmt'ye benzer bir kurallı biçimlendirici içerir. Geçerli dizindeki tüm Android.bp dosyalarını tekrar tekrar biçimlendirmek için şunu çalıştırın:
bpfmt -w .
Kurallı biçim, dört boşluklu girintiler, çok öğeli bir listenin her öğesinden sonra yeni satırlar ve listelerde ve haritalarda bir virgül içerir.
Özel modüller
Bazı özel modül grupları benzersiz özelliklere sahiptir.
Varsayılan modüller
Aynı özellikleri birden çok modülde tekrarlamak için bir varsayılan modül kullanılabilir. Ö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ı muadilleriyle aynı ada sahip olmasına izin verir. Örneğin, aynı ada sahip bir cc_binary zaten varsa, foo adlı bir cc_prebuilt_binary olabilir. Bu, geliştiricilere nihai ürünlerine hangi sürümü dahil edeceklerini seçme esnekliği verir. Bir yapı yapılandırması her iki sürümü de içeriyorsa, önceden oluşturulmuş modül tanımındaki prefer bayrağı değeri hangi sürümün önceliğe sahip olduğunu belirler. Bazı önceden oluşturulmuş modüllerin, android_app_import gibi prebuilt ile başlamayan adlara sahip olduğunu unutmayın.
Ad alanı modülleri
Android, Make'dan Soong'a tamamen dönüşene kadar, Make ürün yapılandırması bir PRODUCT_SOONG_NAMESPACES değeri belirtmelidir. Değeri, Soong'un m komutuyla oluşturulmak üzere Make'a aktardığı ad alanlarının boşlukla ayrılmış bir listesi olmalıdır. Android'in Soong'a dönüştürülmesi tamamlandıktan sonra, ad alanlarını etkinleştirmenin ayrıntıları değişebilir.
Soong, her modül ayrı bir ad alanı içinde bildirildiği sürece, farklı dizinlerdeki modüllere aynı adı belirtme yeteneği sağlar. Bir ad alanı şu şekilde bildirilebilir:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
Bir ad alanının name özelliğine sahip olmadığına dikkat edin; yolu otomatik olarak adı olarak atanır.
Her Soong modülüne, ağaçtaki konumuna göre bir ad alanı atanır. Her Soong modülünün, geçerli dizinde veya en yakın üst dizinde bulunan bir Android.bp dosyasında bulunan soong_namespace tarafından tanımlanan ad alanında olduğu kabul edilir. Böyle bir soong_namespace modülü bulunmazsa, modülün örtük kök ad alanında olduğu kabul edilir.
İşte bir örnek: Soong, I1, I2, I3… ad alanlarını içe aktaran N ad alanında modül M tarafından bildirilen D bağımlılığını çözmeye çalışır.
- Daha sonra D,
//namespace:moduleformunun tam nitelikli bir adıysa, belirtilen modül adı için yalnızca belirtilen ad alanı aranır. - Aksi takdirde, Soong önce N ad alanında bildirilen D adlı bir modülü arar.
- Bu modül yoksa, Soong, I1, I2, I3… ad alanlarında D adlı bir modül arar.
- Son olarak, Soong kök ad alanına bakar.