نظام بناء سونغ

قبل إصدار Android 7.0، استخدم Android GNU Make حصريًا لوصف وتنفيذ قواعد البناء الخاصة به. يتم دعم واستخدام نظام Make build على نطاق واسع، ولكن على نطاق Android أصبح بطيئًا وعرضة للخطأ وغير قابل للتوسع ويصعب اختباره. يوفر نظام بناء Soong المرونة المطلوبة لإصدارات Android.

لهذا السبب، من المتوقع أن يتحول مطورو النظام الأساسي من Make واعتماد Soong في أقرب وقت ممكن. أرسل الأسئلة إلى مجموعة Google الخاصة بنظام Android لتلقي الدعم.

ما هو سونغ؟

تم تقديم نظام بناء Soong في Android 7.0 (Nougat) ليحل محل Make. إنه يستفيد من أداة الاستنساخ Kati GNU Make ومكون نظام بناء Ninja لتسريع عمليات إنشاء Android.

راجع وصف Android Make Build System في مشروع Android مفتوح المصدر (AOSP) للحصول على إرشادات عامة وبناء تغييرات النظام لكتاب Android.mk للتعرف على التعديلات اللازمة للتكيف من Make إلى Soong.

راجع الإدخالات ذات الصلة بالإنشاء في المسرد للحصول على تعريفات للمصطلحات الأساسية وملفات Soong المرجعية للحصول على التفاصيل الكاملة.

جعل و سونغ المقارنة

فيما يلي مقارنة بين إجراء التكوين و Soong الذي ينجز نفس الشيء في ملف تكوين Soong (Blueprint أو .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 مماثلة لملفات Bazel 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 .

أنواع

تتم كتابة المتغيرات والخصائص بقوة، حيث تعتمد المتغيرات ديناميكيًا على المهمة الأولى، ويتم تعيين الخصائص بشكل ثابت بواسطة نوع الوحدة النمطية. الأنواع المدعومة هي:

• القيم المنطقية ( true أو false )
• الأعداد الصحيحة ( int )
• سلاسل ( "string" )
• قوائم السلاسل ( ["string1", "string2"] )
• الخرائط ( {key1: "value1", key2: ["value2"]} )

قد تحتوي الخرائط على قيم من أي نوع، بما في ذلك الخرائط المتداخلة. قد تحتوي القوائم والخرائط على فواصل بعد القيمة الأخيرة.

الكرات

الخصائص التي تأخذ قائمة من الملفات، مثل srcs ، يمكنها أيضًا أن تأخذ أنماطًا شاملة. يمكن أن تحتوي أنماط الكرة الأرضية على حرف البدل UNIX العادي * ، على سبيل المثال *.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++.

العاملين

يمكن إلحاق السلاسل وقوائم السلاسل والخرائط باستخدام عامل التشغيل +. يمكن تلخيص الأعداد الصحيحة باستخدام عامل التشغيل + . يؤدي إلحاق الخريطة إلى اتحاد المفاتيح في كلتا الخريطتين، وإلحاق قيم أي مفاتيح موجودة في كلتا الخريطتين.

الشروط

لا يدعم 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 .

يتضمن التنسيق المتعارف عليه مسافات بادئة بأربع مسافات، وأسطرًا جديدة بعد كل عنصر في قائمة متعددة العناصر، وفاصلة زائدة في القوائم والخرائط.

وحدات خاصة

تتمتع بعض مجموعات الوحدات الخاصة بخصائص فريدة.

الوحدات الافتراضية

يمكن استخدام وحدة الإعدادات الافتراضية لتكرار نفس الخصائص في وحدات متعددة. على سبيل المثال:

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 .

وحدات مساحة الاسم

حتى يتم تحويل Android بالكامل من Make إلى Soong، يجب أن يحدد تكوين المنتج قيمة PRODUCT_SOONG_NAMESPACES . يجب أن تكون قيمتها عبارة عن قائمة مفصولة بمسافات من مساحات الأسماء التي يصدرها Soong إلى Make ليتم بناؤها بواسطة الأمر m . بعد اكتمال تحويل Android إلى Soong، قد تتغير تفاصيل تمكين مساحات الأسماء.

يوفر Soong القدرة للوحدات النمطية الموجودة في أدلة مختلفة لتحديد نفس الاسم، طالما تم الإعلان عن كل وحدة ضمن مساحة اسم منفصلة. يمكن الإعلان عن مساحة الاسم على النحو التالي:

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

لاحظ أن مساحة الاسم لا تحتوي على خاصية اسم؛ يتم تعيين مساره تلقائيًا كاسم له.

يتم تعيين مساحة اسم لكل وحدة Soong بناءً على موقعها في الشجرة. تعتبر كل وحدة Soong موجودة في مساحة الاسم المحددة بواسطة soong_namespace الموجودة في ملف Android.bp في الدليل الحالي أو أقرب دليل سلف. إذا لم يتم العثور على وحدة soong_namespace ، فسيتم اعتبار الوحدة موجودة في مساحة الاسم الجذر الضمنية.

فيما يلي مثال: يحاول Soong حل التبعية D المعلنة بواسطة الوحدة M في مساحة الاسم N التي تستورد مساحات الأسماء I1 وI2 وI3...

1. ثم إذا كان D اسمًا مؤهلاً بالكامل للنموذج //namespace:module ، فسيتم البحث في مساحة الاسم المحددة فقط عن اسم الوحدة النمطية المحددة.
2. بخلاف ذلك، يبحث Soong أولاً عن الوحدة النمطية المسماة D المعلنة في مساحة الاسم N.
3. إذا لم تكن هذه الوحدة موجودة، يبحث Soong عن وحدة تسمى D في مساحات الأسماء I1 وI2 وI3...
4. وأخيرًا، يبحث Soong في مساحة الاسم الجذر.