نظام البناء Soong

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

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

ما هو Soong؟

و بناء نظام سونغ تم تقديمها في الروبوت 7.0 (نوجا) ليحل محل الصنع. ويستفيد من كاتي GNU أداة إجراء استنساخ و النينجا عنصر بناء نظام لتسريع بناء الروبوت.

اطلع على جعل بناء الروبوت نظام الوصف في مشروع مفتوح المصدر أندرويد (AOSP) للالعامة تعليمات و بناء التغييرات نظام لAndroid.mk الكتاب لمعرفة المزيد عن التعديلات اللازمة للتكيف مع من جعل لسونغ.

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

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

هنا هو المقارنة بين التكوين وجعل مع سونغ إنجاز نفسه في تكوين سونغ (مخطط أو .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)

مثال Soong

cc_library_shared {
     name: “libxmlrpc++”,

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

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

انظر تكوين بناء بسيط للحصول على أمثلة التهيئة اختبار محددة سونغ.

تنسيق ملف 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>" .

للحصول على قائمة من أنواع حدة صالحة وممتلكاتهم، راجع سونغ وحدات المرجعي .

أنواع

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

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

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

جلوبس

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

يتم تحديد نطاق المتغيرات لبقية الملف الذي تم الإعلان عنه فيه ، بالإضافة إلى أي ملفات Blueprint تابعة. المتغيرات ثابتة مع استثناء واحد: يمكن إلحاق مع += المهمة، ولكن فقط قبل لقد تم المشار إليه.

تعليقات

Android.bp يمكن أن تحتوي الملفات على غرار C متعدد /* */ وC ++ أسلوب سطر واحد // التعليقات.

العاملين

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

الشرطية

سونغ لا يدعم الشرطية في Android.bp الملفات. بدلاً من ذلك ، يتم التعامل مع التعقيد في قواعد الإنشاء التي تتطلب شروطًا في Go ، حيث يمكن استخدام ميزات اللغة عالية المستوى ، ويمكن تتبع التبعيات الضمنية التي قدمتها الشروط. يتم تحويل معظم الشروط إلى خاصية خريطة ، حيث يتم تحديد إحدى القيم الموجودة في الخريطة وإلحاقها بخصائص المستوى الأعلى.

على سبيل المثال ، لدعم الملفات الخاصة بالبنية:

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

المنسق

يشمل سونغ والمنسق الكنسي لملفات مخطط، على غرار 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 .

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

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

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

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

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

يتم تخصيص مساحة اسم لكل وحدة من وحدات 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 في مساحة اسم الجذر.