דף זה תורגם על ידי Cloud Translation API.

המרה מ'לעשות' ל'סונג'

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

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

מהו Soong?

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

ראו את Android Make Build System בתיאור בפרויקט הקוד הפתוח של Android (AOSP) לקבלת הנחיות כלליות הוראות וגם Build System Changes for Android.mk Writer.

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

השוואה – ביצוע וצליל

בהמשך מופיעה השוואה בין הגדרת Make לבין הגדרת 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 ספציפיות לבדיקה מפורטות במאמר הגדרת 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 ל-Soong יושלם, צריך לציין ערך PRODUCT_SOONG_NAMESPACES בהגדרות המוצר ב-Make. הערך שלו צריך להיות רשימה של מרחבי שמות מופרדים בפסיקים, ש-Soong מייצא ל-Make כדי שייבנו באמצעות הפקודה m. אחרי שההמרה של Android ל-Soong תושלם, הפרטים של הפעלת מרחבי שמות עשויים להשתנות.

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

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

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

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

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

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