Google is committed to advancing racial equity for Black communities. See how.
דף זה תורגם על ידי Cloud Translation API.
Switch to English

מערכת Soong Build

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

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

מה זה סונג?

מערכת ה- Soong build הוצגה באנדרואיד 7.0 (נוגט) כדי להחליף את Make. הוא ממנף את כלי השיבוט של Kati GNU Make ורכיב מערכת לבניית הנינג'ה כדי להאיץ את בניית Android.

עיין בתיאור Android Make Build System בפרויקט קוד פתוח של Android (AOSP) לקבלת הוראות כלליות ושינויים בבניית מערכת עבור סופרי Android.mk כדי ללמוד על שינויים הדרושים להתאמה בין Make to Soong.

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

ערוך והשוואה של Soong

להלן השוואה בין יצירת תצורה ל- Soong בהשגת אותה בקובץ תצורה של .bp (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)

דוגמה כל כך טובה

cc_library_shared {
     name: “libxmlrpc++”,

     rtti: true,
     cppflags: [
           “-Wall”,
           “-Werror”,
           “-fexceptions”,
     ],
     export_include_dirs: [“src”],
     srcs: [“src/**/*.cpp”],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

ראה תצורת Build Build פשוטה לקבלת דוגמאות לתצורה ספציפית של 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 .

סוגים

משתנים ומאפיינים מוקלדים מאוד, כאשר המשתנים מבוססים באופן דינמי על ההקצאה הראשונה, ומאפיינים מוגדרים באופן סטטי לפי סוג המודול. הסוגים הנתמכים הם:

  • Booleans ( true או false )
  • שלמים ( int )
  • מיתרים ( "string" )
  • רשימות מחרוזות ( ["string1", "string2"] )
  • מפות ( {key1: "value1", key2: ["value2"]} )

מפות עשויות להכיל ערכים מכל סוג שהוא, כולל מפות מקוננות. רשימות ומפות עשויות לכלול פסיקים נגררים לאחר הערך האחרון.

גלובס

מאפיינים שלוקחים רשימת קבצים, כגון srcs , יכולים גם הם לקחת תבניות גלוב. דפוסי גלוב יכולים להכיל את התו הכללי הרגיל של UNIX * , למשל *.java . תבניות גלוב יכולות להכיל גם תו כללי ** יחיד כאלמנט נתיב, התואם לאפס אלמנטים של נתיב. לדוגמה, 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 רב-קו /* */ ו- 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 .

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

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

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

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

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

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

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

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