فرمت فایل Android.bp

از نظر طراحی، فایل‌های 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 مراجعه کنید.

انواع

متغیرها و ویژگی ها به شدت تایپ می شوند، با متغیرها به صورت پویا بر اساس اولین انتساب، و ویژگی ها به صورت ایستا توسط نوع ماژول تنظیم می شوند. انواع پشتیبانی شده عبارتند از:

• بولی ها ( true یا false )
• اعداد صحیح ( int )
• رشته ها ( "string" )
• لیست رشته ها ( ["string1", "string2"] ]
• Maps ( {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",
}

متغیرها به باقیمانده فایلی که در آن اعلان شده اند و همچنین هر فایل Blueprint فرزندی محدود می شوند. متغیرها با یک استثنا تغییر ناپذیر هستند: آنها را می توان با یک تخصیص += به آنها اضافه کرد، اما فقط قبل از اینکه به آنها ارجاع داده شود.

نظرات

فایل‌های 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_binary با همین نام وجود داشته باشد، می‌تواند یک cc_prebuilt_binary به نام foo وجود داشته باشد. این به توسعه دهندگان این امکان را می دهد که انتخاب کنند کدام نسخه را در محصول نهایی خود قرار دهند. اگر یک پیکربندی ساخت شامل هر دو نسخه باشد، مقدار پرچم prefer در تعریف ماژول از پیش ساخته شده دیکته می‌کند که کدام نسخه اولویت دارد. توجه داشته باشید که برخی از ماژول های از پیش ساخته شده دارای نام هایی هستند که با prebuilt شروع نمی شوند، مانند android_app_import .

ماژول های فضای نام

تا زمانی که Android به طور کامل از 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 را وارد می کند، حل کند.

1. سپس اگر D یک نام کاملا واجد شرایط از فرم //namespace:module باشد، فقط فضای نام مشخص شده برای نام ماژول مشخص شده جستجو می شود.
2. در غیر این صورت، سونگ ابتدا به دنبال یک ماژول به نام D اعلام شده در فضای نام N می گردد.
3. اگر آن ماژول وجود نداشته باشد، Soong به دنبال ماژولی به نام D در فضاهای نام I1، I2، I3 می گردد.
4. Soong در فضای نام ریشه نگاه می کند.

شرایط

Soong از شرطی ها در فایل های Android.bp پشتیبانی نمی کند. در عوض، پیچیدگی در قوانین ساخت که به شرطی‌ها نیاز دارند، در Go، جایی که می‌توان از ویژگی‌های زبان سطح بالا استفاده کرد، و وابستگی‌های ضمنی معرفی‌شده توسط شرطی‌ها را می‌توان ردیابی کرد. اکثر شرط ها به یک ویژگی نقشه تبدیل می شوند، جایی که یکی از مقادیر موجود در نقشه انتخاب شده و به ویژگی های سطح بالا اضافه می شود.

به عنوان مثال، برای پشتیبانی از فایل های خاص معماری:

cc_library {
    ...
    srcs: ["generic.cpp"],
    arch: {
        arm: {
            srcs: ["arm.cpp"],
        },
        x86: {
            srcs: ["x86.cpp"],
        },
    },
}

فرمت کننده

Soong شامل یک قالب‌کننده متعارف برای فایل‌های Blueprint، مشابه gofmt است. برای قالب‌بندی مجدد همه فایل‌های Android.bp در فهرست فعلی، اجرا کنید:

bpfmt -w .

قالب متعارف شامل تورفتگی های چهار فاصله، خطوط جدید بعد از هر عنصر از یک لیست چند عنصری، و یک کاما انتهایی در لیست ها و نقشه ها است.