Soong Yapı Sistemi

Android 7.0 sürümden önce Android kullanılan GNU Make tanımlamak ve yapı kurallarını çalıştırmak münhasıran. Make derleme sistemi yaygın olarak destekleniyor ve kullanılıyor, ancak Android ölçeğinde yavaşladı, hataya açık, ölçeklenemez ve test edilmesi zor hale geldi. Soong inşa sistemi Android kurar için gerekli esnekliği sağlar.

Bu nedenle platform geliştiricilerinin en kısa sürede Make and benimsemek Soong'dan geçiş yapması bekleniyor. Soru Gönder android-bina destek almaya Google Grubu.

Soong nedir?

Soong inşa sistemi Make yerine Android 7.0 (Nugat) kullanılmaya başlandı. Bu güçlendirir Kati GNU Make klon aracı ve Ninja Android'in inşa hızlandırmak için inşa sistem bileşenini.

Bkz Android Yap Yapı Sistemi generale Android Açık Kaynak Projesi (AOSP) açıklamayı talimatlar ve Android.mk Yazarlar Sistem Değişiklikleri kurmak Soong için Make gelen uyum için gerekli değişiklikler hakkında bilgi edinmek için.

Bkz birikmesi ilgili girişleri anahtar terimler ve tanımları için sözlükte Soong referans dosyalarının tüm ayrıntılar için.

Yap ve Yakında karşılaştırması

İşte Soong bir Soong konfigürasyonu (Blueprint veya aynı gerçekleştirerek ile yap yapılandırmasının bir karşılaştırma bulunmaktadır .bp ) dosyası.

Ö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,
           },
     },
}

Bkz Basit Yapı Yapılandırma testi özgü Soong yapılandırma örnekleri için.

Android.bp dosya biçimi

Tasarım gereği, Android.bp dosyaları basittir. Koşullar veya kontrol akışı ifadeleri içermezler; tüm karmaşıklık, Go'da yazılmış yapı mantığıyla ele alınır. Mümkün olduğunda, sözdizimi ve anlambilim Android.bp dosyalarına benzer Bazel YAPI dosyaları .

Modüller

Bir in bir modül Android.bp bir dosya başlar modül türündeki mülklerin bir dizi izledi name: "value", formatında:

cc_binary {
    name: "gzip",
    srcs: ["src/test/minigzip.c"],
    shared_libs: ["libz"],
    stl: "none",
}

Her modül olmalıdır name özelliği ve değer tüm arasında benzersiz olmalıdır Android.bp haricinde dosyalar name tekrarlayabilir ad ve önceden oluşturulmuş modüllerde gayrimenkul değerleri.

srcs mülkiyet belirtir dizeleri bir liste olarak modül oluşturmak için kullanılan kaynak dosyalarını. Sen gibi, kaynak dosyaları üretmek diğer modüllerin çıkışını başvurabilir genrule veya filegroup , modül referans sözdizimi kullanarak ":<module-name>" .

Geçerli modül tipleri ve özellikleri listesi için bkz Soong Modülleri Referans .

Türler

Değişkenler ve özellikler, ilk atamaya dayalı olarak 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 ( true veya false )
  • Tamsayılar ( int )
  • Dizeleri ( "string" )
  • Dizeleri Listeleri ( ["string1", "string2"] )
  • Harita ( {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

Gibi dosyaların bir listesini almak Özellikleri, srcs , ayrıca glob desen alabilir. Glob desenler normal bir Unix Joker içerebilir * örneğin *.java . Glob desen de tek içerebilir ** sıfır ya da daha fazla yol öğelerini uygun bir yol elemanı olarak joker. Örneğin, java/**/*.java hem maçları java/Main.java ve java/com/android/Main.java desenleri.

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şmez: onlar bir ile eklenebilir += atama, ancak başvurulan oldum önce sadece.

Yorumlar

Android.bp dosyalar C tarzı çok satırlı içerebilir /* */ C ++ tarzı tek hat // yorumlar.

operatörler

Diziler, dizi listeleri ve haritalar + operatörü kullanılarak eklenebilir. Tamsayılar kullanılarak özetlenebilir + operatör. Bir harita eklemek, her iki haritada da bulunan anahtarların değerlerini ekleyerek her iki haritada da anahtar birleşimini üretir.

Şartlılar

Soong conditionals desteklemez Android.bp dosyaları. 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 benzer Blueprint dosyaları için bir kanonik Biçemleyici içerir gofmt . To ardışık tüm biçimlendirmek Android.bp çalıştırmak geçerli dizinde, dosyaları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, bir olabilir cc_prebuilt_binary adlı foo zaten varken cc_binary aynı adla. 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ü içeriyorsa, prefer önceliği vardır sürümü önceden oluşturulmuş modül tanım dikte bayrak değerini. Bazı önceden oluşturulmuş modülleri ile başlamayın adlara sahip Not prebuilt gibi android_app_import .

Ad alanı modülleri

Android tam Soong için Make den dönüştürür kadar, yap ürün konfigürasyonu bir belirtmelisiniz PRODUCT_SOONG_NAMESPACES değeri. Onun değeri Soong ihracatı tarafından inşa edilecek Make bu ad bir boşlukla ayrılmış liste olmalıdır m komutu. 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ü tarafından tanımlanan ad olarak kabul edilir soong_namespace bir bulundu Android.bp geçerli dizinde ya da en yakın atası dizinindeki dosyasında. Böyle olursa soong_namespace modülü bulunursa, modül örtülü kök ad alanında olduğu düşünülür.

İş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.

  1. Sonra D tam yetkili bir formu adıysa //namespace:module , sadece belirtilen ad belirtilen modül adı aranır.
  2. Aksi takdirde, Soong önce N ad alanında bildirilen D adlı bir modülü arar.
  3. Bu modül yoksa, Soong, I1, I2, I3… ad alanlarında D adlı bir modül arar.
  4. Son olarak, Soong kök ad alanına bakar.