Google is committed to advancing racial equity for Black communities. See how.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

نظام البناء Soong

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

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

ما هو Soong؟

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

راجع وصف Android Make Build System في مشروع Android Open Source Project (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)

مثال Soong

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 ( int )
  • سلاسل ( "string" )
  • قوائم السلاسل ( ["string1", "string2"] سلسلة 1 ["string1", "string2"] )
  • الخرائط ( {key1: "value1", key2: ["value2"]} )

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

جلوبس

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

العاملين

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

الشرطية

لا يدعم 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 في مساحة اسم الجذر.