سیستم ساخت سونگ

قبل از انتشار آندروید 7.0، آندروید استفاده می شود گنو میک منحصرا برای توصیف و اجرای قوانین ساخت آن است. سیستم Make build به طور گسترده پشتیبانی و استفاده می شود ، اما در مقیاس اندروید آهسته ، مستعد خطا ، غیر قابل مقیاس و آزمایش آن دشوار شد. سیستم ساخت Soong انعطاف پذیری مورد نیاز برای ایجاد آندروید فراهم می کند.

به همین دلیل ، انتظار می رود که توسعه دهندگان پلت فرم از Make تغییر کرده و Soong را در اسرع وقت انتخاب کنند. ارسال سوالات به نرم افزار android-ساخت گروه گوگل برای دریافت پشتیبانی.

سونگ چیست؟

سیستم ساخت Soong در آندروید 7.0 (حلوای مغز دار) به جای میک معرفی شد. این اهرم کتی گنو ابزار کلون ایجاد و نینجا سیستم ساخت جزء برای سرعت بخشیدن به ایجاد از اندیشه است.

مراجعه کنید میک ساخت سیستم آندروید توضیحات در اندیشه پروژه منبع باز (AOSP) برای به طور کلی دستورالعمل و ساخت سیستم تغییرات برای Android.mk نویسندگان به تغیرات لازم برای انطباق از را به Soong یاد بگیرند.

مشاهده نوشته های مرتبط با ساخت در واژه نامه برای تعاریف اصطلاحات کلیدی و فایل های Soong مرجع برای جزئیات کامل.

مقایسه کنید و مقایسه کنید

در اینجا یک مقایسه از پیکربندی را با Soong انجام همان در یک پیکربندی Soong (طرح یا .bp ) فایل.

مثال بزنید

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)

مثال سونگ

cc_library_shared {
     name: “libxmlrpc++”,

     rtti: true,
     cppflags: [
           “-Wall”,
           “-Werror”,
           “-fexceptions”,
     ],
     export_include_dirs: [“src”],
     srcs: [“src/**/*.cpp”],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

مشاهده تنظیمات ساخت ساده برای پیکربندی نمونه هایی از آزمون خاص Soong.

فرمت فایل Android.bp

با طراحی، Android.bp فایل های ساده هستند. آنها شامل شرط ها یا گزاره های جریان کنترل نیستند. تمام پیچیدگی ها با منطق ساخت که در Go نوشته شده است مدیریت می شود. در صورت امکان، نحو و معناشناسی Android.bp فایل های شبیه به فایل های BUILD بازل .

ماژول ها

یک ماژول در یک Android.bp شروع می شود فایل با نوع ماژول به دنبال مجموعه ای از خواص در name: "value", فرمت:

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

هر ماژول باید یک name اموال، و ارزش باید منحصر به فرد در تمام می شود Android.bp فایل، به جز برای name ارزش املاک در فضای نام ها و ماژول های پیش ساخته، که ممکن است تکرار کنید.

srcs مشخص اموال فایل های منبع مورد استفاده برای ساخت ماژول، به عنوان یک لیست از رشته ها. شما می توانید خروجی ماژول های دیگر است که برای تولید فایل های منبع، مانند مرجع genrule یا filegroup ، با استفاده از نحو ماژول مرجع ":<module-name>" .

برای یک لیست از انواع ماژول معتبر و خواص آنها، دیدن Soong ماژول مرجع .

انواع

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

  • Booleans می ( true یا false )
  • اعداد صحیح ( int )
  • رشته ( "string" )
  • لیست از رشته ها ( ["string1", "string2"] )
  • نقشه ها ( {key1: "value1", key2: ["value2"]} )

نقشه ها ممکن است حاوی مقادیر هر نوع ، از جمله نقشه های تو در تو باشند. لیست ها و نقشه ها ممکن است بعد از آخرین مقدار دارای کاما باشند.

گلوب

خواص است که یک لیست از فایل، مانند srcs ، همچنین می توانید الگوهای جانشین است. الگوهای جانشین آن می تواند شامل نرمال یونیکس از کلمات * ، برای مثال *.java . الگوهای جانشین همچنین می تواند شامل یک ** کلمات به عنوان یک عنصر مسیر، که صفر یا بیشتر از عناصر مسیر. به عنوان مثال، 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 ++ به سبک تک خط // نظر.

اپراتورها

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

مشروط

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

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

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

قالب ساز

Soong شامل یک قالب استاندارد را برای فایل های طرح، شبیه به gofmt . به صورت بازگشتی مجدد تمام Android.bp فایل های موجود در دایرکتوری جاری، را اجرا کنید:

bpfmt -w .

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

ماژول های ویژه

برخی از گروه های ماژول ویژه دارای ویژگی های منحصر به فردی هستند.

ماژول های پیش فرض

یک ماژول پیش فرض می تواند برای تکرار ویژگی های یکسان در چندین ماژول استفاده شود. مثلا:

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 ارزش پرچم در ماژول ارائه میشود دیکته تعریف که نسخه دارای اولویت است. توجه داشته باشید که برخی از ماژول های پیش ساخته نام که با شروع نشد prebuilt ، مانند android_app_import .

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

تا زمانی که آندروید به طور کامل از را به Soong تبدیل، پیکربندی محصول را باید یک مشخص PRODUCT_SOONG_NAMESPACES ارزش. ارزش خود را باید یک لیست فاصله از هم جدا از فضاهای نام شود که صادرات Soong را به به بود، ساخته شد m فرمان. پس از اتمام تبدیل اندروید به سونگ ، جزئیات فعال کردن فضاهای نام ممکن است تغییر کند.

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

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

توجه داشته باشید که یک فضای نام دارای ویژگی نام نیست. مسیر آن به طور خودکار به عنوان نام اختصاص داده می شود.

به هر ماژول Soong یک فضای نام بر اساس موقعیت آن در درخت اختصاص داده شده است. هر ماژول Soong در نظر گرفته می در فضای نام تعریف شده توسط شود soong_namespace پیدا شده در یک Android.bp فایل در دایرکتوری جاری و یا نزدیک ترین دایرکتوری جد. اگر چنین soong_namespace ماژول پیدا شده است، ماژول در نظر گرفته می در فضای نام ریشه ضمنی باشد.

در اینجا یک مثال آورده شده است: تلاش های پی در پی برای رفع وابستگی D اعلام شده توسط ماژول M در فضای نام N که فضاهای نام I1 ، I2 ، I3 را وارد می کند…

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