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

מערכת build של Sog

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

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

מהו Soong?

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

בתיאור של מערכת Android Make Build בפרויקט Android Open Source Project‏ (AOSP) מפורטות הוראות כלליות, ובשינויים במערכת ה-build לכותבי Android.mk מפורטות ההתאמות הנדרשות כדי לעבור מ-Make ל-Soong.

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

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

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

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

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

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

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

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

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