מערכת build של Sog

לפני השקת הגרסה של Android 7.0, מערכת Android השתמשה ב-GNU Maker באופן בלעדי כדי לתאר ולהפעיל את כללי ה-build שלה. מערכת ה-build של Maker נתמכת מאוד ומשתמשת בה, אבל בקנה מידה גדול של Android הפכה לאטית, מכילה יותר שגיאות, לא ניתנת להתאמה וקשה לבדיקה. מערכת ה-build של Soong מספקת את הגמישות הדרושה לגרסאות ה-build של Android.

לכן אנחנו מצפים שמפתחי פלטפורמה לעבור מ-Maker ולאמץ את Soong בהקדם האפשרי. כדי לקבל תמיכה, אפשר לשלוח שאלות לקבוצה ב-Google לבני android.

מה זה סונג?

מערכת ה-build של Sog הושקה ב-Android 7.0 (Nougat) כדי להחליף את Maker. הוא משתמש בכלי השכפול של Kati GNU Maker וברכיב המערכת של Ninja כדי להאיץ את גרסאות ה-build של Android.

לקבלת הוראות כלליות ו-Build System Changes for Android.mk Writers, תוכלו לקרוא את התיאור של Android Make Build System בפרויקט קוד פתוח של Android (AOSP).

לפרטים מלאים עיינו ברשומות שקשורות ל-build במילון המונחים כדי לראות את ההגדרות של מונחי המפתח, ובקובצי העזר של Soong.

השוואה לשוק וסונג

הנה השוואה בין ההגדרות האישיות של Create ו-Songg שמבצעת את אותה פעולה בקובץ ההגדרות האישיות של במהירות (Sung) (לוגו או .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,
           },
     },
}

לדוגמאות ספציפיות לבדיקה, ראו Simple Build Configuration (הגדרה פשוטה של build).

להסבר על השדות בקובץ Android.bp, אפשר לעיין בפורמט הקובץ Android.bp.

מודולים מיוחדים

לחלק מקבוצות המודולים המיוחדות יש מאפיינים ייחודיים.

מודולים של ברירות מחדל

ניתן להשתמש במודול ברירת מחדל כדי לחזור על אותם מאפיינים במספר מודולים. לדוגמה:

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 באותו שם. כך המפתחים יכולים לבחור איזו גרסה לכלול במוצר הסופי. אם תצורת build מכילה את שתי הגרסאות, ערך הדגל prefer בהגדרת המודול מראש קובע לאיזו גרסה תהיה עדיפות. שימו לב שלחלק מהמודולים שהוגדרו מראש יש שמות שלא מתחילים ב-prebuilt, כמו android_app_import.

מודולים של מרחב שמות

עד ש-Android יבצע את ההמרה המלאה מ-Make ל-Songg, עליך לציין ערך PRODUCT_SOONG_NAMESPACES בהגדרת המוצר Make. הערך שלו צריך להיות רשימה של מרחבי שמות שמופרדים ברווחים, ש-Songg מייצא ל-Make, כדי להיבנות על ידי הפקודה m. לאחר השלמת ההמרה של Android ל-Songg, הפרטים של הפעלת מרחבי השמות עשויים להשתנות.

Sung מאפשר למודולים בספריות שונות לציין את אותו שם, כל עוד כל מודול מוצהר במרחב שמות נפרד. אפשר להצהיר על מרחב שמות כך:

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

שימו לב שלמרחב השמות אין מאפיין שם. הנתיב שלו מוקצה באופן אוטומטי כשם.

לכל מודול Sung מוקצה מרחב שמות על סמך המיקום שלו בעץ. כל מודול Sog נחשב כמרחב השמות שמוגדר על ידי soong_namespace שנמצא בקובץ Android.bp בספרייה הנוכחית או בספריית ישות האב הקרובה ביותר. אם לא נמצא מודול soong_namespace כזה, הוא נחשב כמרחב השמות המשתמע של הרמה הבסיסית (root).

לדוגמה: סונג מנסה לפתור את התלות D שהוצהרה על ידי מודול M במרחב השמות N, שמייבא מרחבי שמות I1, I2, I3...

  1. לאחר מכן, אם D הוא שם שמוגדר במלואו מהטופס //namespace:module, יתבצע חיפוש רק במרחב השמות שצוין.
  2. אחרת, סונג מחפש קודם מודול בשם D שהוצהר במרחב השמות N.
  3. אם המודול הזה לא קיים, סונג מחפש מודול בשם D במרחבי השמות I1, I2, I3...
  4. לבסוף, סונג מחפש את מרחב השמות של הרמה הבסיסית (root).