فایلهای Android.bp از نظر طراحی، سرراست هستند. آنها حاوی دستورات شرطی یا جریان کنترلی نیستند؛ تمام پیچیدگیها توسط منطق ساخت نوشته شده در Go مدیریت میشود.
ماژولها
یک ماژول در فایل Android.bp با نوع ماژول شروع میشود و به دنبال آن مجموعهای از ویژگیها با name: "value", فرمت زیر قرار میگیرد:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
هر ماژول باید یک ویژگی name داشته باشد و مقدار آن باید در تمام فایلهای Android.bp منحصر به فرد باشد، به جز مقادیر ویژگی name در فضاهای نام و ماژولهای از پیش ساخته شده که ممکن است تکرار شوند.
ویژگی srcs فایلهای منبع مورد استفاده برای ساخت ماژول را به صورت لیستی از رشتهها مشخص میکند. میتوانید با استفاده از سینتکس ارجاع ماژول ":<module-name>" به خروجی ماژولهای دیگری که فایلهای منبع تولید میکنند، مانند genrule یا filegroup ، ارجاع دهید.
برای فهرستی از انواع ماژولهای معتبر و ویژگیهای آنها، به مرجع ماژولهای Soong که با اجرای m soong_docs تولید شده است، مراجعه کنید. خروجی در out/soong/docs/soong_build.html خواهد بود.
انواع
متغیرها و ویژگیها به شدت تایپ میشوند، متغیرها به صورت پویا بر اساس اولین انتساب تنظیم میشوند و ویژگیها به صورت ایستا توسط نوع ماژول تنظیم میشوند. انواع پشتیبانی شده عبارتند از:
- بولیها (
trueیاfalse) - اعداد صحیح (
int) - رشتهها (
"string") - لیست رشتهها (
["string1", "string2"]) - نقشهها (
{key1: "value1", key2: ["value2"]})
نقشهها میتوانند شامل مقادیری از هر نوع، از جمله نقشههای تو در تو باشند. لیستها و نقشهها میتوانند بعد از آخرین مقدار، کاما داشته باشند.
گلوبها
ویژگیهایی که لیستی از فایلها را میگیرند، مانند srcs ، میتوانند الگوهای glob نیز بپذیرند. الگوهای glob میتوانند شامل کاراکترهای جایگزین معمولی یونیکس * باشند، برای مثال *.java . الگوهای glob همچنین میتوانند شامل یک کاراکتر جایگزین ** به عنوان عنصر مسیر باشند که با صفر یا چند عنصر مسیر مطابقت دارد. برای مثال، java/**/*.java با هر دو الگوی java/Main.java و java/com/android/Main.java مطابقت دارد.
متغیرها
یک فایل Android.bp ممکن است شامل انتساب متغیرهای سطح بالا باشد:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
متغیرها به بقیه فایلی که در آن تعریف شدهاند، و همچنین هر فایل طرح فرزند، محدود میشوند. متغیرها تغییرناپذیر هستند، با یک استثنا: میتوان آنها را با یک انتساب += به هم اضافه کرد، اما فقط قبل از اینکه به آنها ارجاع داده شده باشد.
نظرات
فایلهای Android.bp میتوانند شامل توضیحات چندخطی /* */ به سبک C و توضیحات تکخطی // به سبک C++ باشند.
اپراتورها
رشتهها، لیست رشتهها و نقشهها را میتوان با استفاده از عملگر + به هم اضافه کرد. اعداد صحیح را میتوان با استفاده از عملگر + خلاصه کرد. اضافه کردن یک نقشه، اتحاد کلیدها را در هر دو نقشه ایجاد میکند و مقادیر هر کلیدی را که در هر دو نقشه وجود دارد، به هم اضافه میکند.
ماژولهای پیشفرض
توسعهدهندگان میتوانند از یک ماژول پیشفرض برای تکرار ویژگیهای یکسان در چندین ماژول استفاده کنند. برای مثال:
cc_defaults {
name: "gzip_defaults",
shared_libs: ["libz"],
stl: "none",
}
cc_binary {
name: "gzip",
defaults: ["gzip_defaults"],
srcs: ["src/test/minigzip.c"],
}
ماژولهای از پیش ساخته شده
برخی از انواع ماژولهای از پیش ساخته شده به یک ماژول اجازه میدهند که نامی مشابه با همتایان مبتنی بر منبع خود داشته باشد. برای مثال، میتوان یک cc_prebuilt_binary با نام foo داشت در حالی که از قبل یک cc_binary با همان نام وجود دارد. این به توسعهدهندگان این انعطافپذیری را میدهد که کدام نسخه را در محصول نهایی خود بگنجانند. اگر یک پیکربندی ساخت شامل هر دو نسخه باشد، مقدار prefer flag در تعریف ماژول از پیش ساخته شده، اولویت را تعیین میکند. توجه داشته باشید که برخی از ماژولهای از پیش ساخته شده نامهایی دارند که با prebuilt شروع نمیشوند، مانند android_app_import .
ماژولهای فضای نام
تا زمانی که اندروید به طور کامل از Make به Soong تبدیل شود، پیکربندی محصول Make باید مقدار PRODUCT_SOONG_NAMESPACES را مشخص کند. مقدار آن باید لیستی از فضاهای نام باشد که با فاصله از هم جدا شدهاند و Soong آنها را به Make صادر میکند تا توسط دستور m ساخته شوند. پس از تکمیل تبدیل اندروید به Soong، جزئیات فعالسازی فضاهای نام میتواند تغییر کند.
Soong این قابلیت را برای ماژولها در دایرکتوریهای مختلف فراهم میکند که نام یکسانی را مشخص کنند، مادامی که هر ماژول در یک فضای نام جداگانه تعریف شده باشد. توسعهدهندگان میتوانند یک فضای نام تعریف کنند:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
توجه داشته باشید که یک فضای نام، ویژگی name ندارد؛ مسیر آن به طور خودکار به عنوان نامش تعیین میشود.
به هر ماژول Soong بر اساس موقعیتش در درخت، یک فضای نام اختصاص داده میشود. هر ماژول Soong در فضای نامی که توسط soong_namespace موجود در یک فایل Android.bp در دایرکتوری فعلی یا نزدیکترین دایرکتوری جد تعریف شده است، در نظر گرفته میشود. اگر چنین ماژول soong_namespace یافت نشود، ماژول در فضای نام ریشه ضمنی در نظر گرفته میشود.
به عنوان مثال، Soong تلاش میکند وابستگی D را که توسط ماژول M در فضای نام N که فضاهای نام I1، I2، I3 را وارد میکند، حل کند…
- سپس اگر D یک نام کاملاً واجد شرایط به شکل
//namespace:moduleباشد، فقط فضای نام مشخص شده برای نام ماژول مشخص شده جستجو میشود. - در غیر این صورت، سونگ ابتدا به دنبال ماژولی با نام D میگردد که در فضای نام N اعلان شده باشد.
- اگر آن ماژول وجود نداشته باشد، سونگ به دنبال ماژولی با نام D در فضاهای نام I1، I2، I3… میگردد.
- سونگ در فضای نام ریشه جستجو میکند.
جملات شرطی
سونگ از شرطها در فایلهای Android.bp پشتیبانی نمیکند. در عوض، پیچیدگی در قوانین ساخت که نیاز به شرطها دارند، در Go مدیریت میشوند، جایی که میتوان از ویژگیهای زبان سطح بالا استفاده کرد و وابستگیهای ضمنی معرفی شده توسط شرطها را میتوان ردیابی کرد. اکثر شرطها به یک ویژگی نقشه تبدیل میشوند، که در آن یکی از مقادیر موجود در نقشه انتخاب شده و به ویژگیهای سطح بالا اضافه میشود.
برای مثال، برای پشتیبانی از فایلهای مختص معماری:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
قالببند
Soong شامل یک قالببندی استاندارد برای فایلهای Blueprint است، مشابه gofmt . برای قالببندی مجدد بازگشتی تمام فایلهای Android.bp در دایرکتوری فعلی، دستور زیر را اجرا کنید:
bpfmt -w .
قالب متعارف شامل تورفتگیهای چهار فاصلهای، خطوط جدید بعد از هر عنصر از یک لیست چند عنصری و یک ویرگول انتهایی در لیستها و نقشهها است.