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

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

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

מהו 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 ל-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,
           },
     },
}

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

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

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

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

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

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

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