ระบบสร้างซอง

ก่อนการเปิดตัว Android 7.0 Android ใช้ GNU Make เพื่ออธิบายและดำเนินการกฎการสร้างโดยเฉพาะ ระบบ Make build ได้รับการสนับสนุนและใช้งานอย่างกว้างขวาง แต่ในระดับของ Android นั้นช้า เกิดข้อผิดพลาดขึ้น ไม่สามารถปรับขนาดได้ และทดสอบได้ยาก ระบบบิลด์ของ Soong มอบความยืดหยุ่นที่จำเป็นสำหรับบิลด์ Android

ด้วยเหตุนี้ นักพัฒนาแพลตฟอร์มจึงควรเปลี่ยนจาก Make และนำ Soong มาใช้โดยเร็วที่สุด ส่งคำถามไปที่ Google Group ที่ สร้าง Android เพื่อรับการสนับสนุน

ซองคืออะไร

ระบบบิลด์ Soong ถูกนำมาใช้ใน Android 7.0 (Nougat) เพื่อแทนที่ Make ใช้ประโยชน์จากเครื่องมือโคลน Kati GNU Make และส่วนประกอบระบบ Ninja build เพื่อเพิ่มความเร็วในการสร้าง Android

ดูคำอธิบาย ระบบ Android Make Build ใน Android Open Source Project (AOSP) สำหรับ คำแนะนำ ทั่วไปและ Build System Changes สำหรับ Android.mk Writers เพื่อเรียนรู้เกี่ยวกับการปรับเปลี่ยนที่จำเป็นในการปรับจาก Make to Soong

ดู รายการที่เกี่ยวข้องกับบิล ด์ในอภิธานศัพท์สำหรับคำจำกัดความของคำศัพท์สำคัญและ ไฟล์อ้างอิง Soong สำหรับรายละเอียดทั้งหมด

Make และ Soon เปรียบเทียบ

นี่คือการเปรียบเทียบ Make configuration กับ Soong ที่ทำสิ่งเดียวกันให้สำเร็จในไฟล์การกำหนดค่า Soong (พิมพ์เขียวหรือ .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 อย่างง่าย สำหรับตัวอย่างการกำหนดค่า 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

ประเภท

ตัวแปรและคุณสมบัติถูกพิมพ์อย่างเข้มงวด โดยมีตัวแปรแบบไดนามิกตามการกำหนดครั้งแรก และคุณสมบัติตั้งค่าแบบคงที่ตามประเภทโมดูล ประเภทที่รองรับคือ:

• บูลีน ( true หรือ false )
• จำนวนเต็ม ( int )
• สตริง ( "string" )
• รายการสตริง ( ["string1", "string2"] )
• แผนที่ ( {key1: "value1", key2: ["value2"]} )

แผนที่อาจมีค่าทุกประเภท รวมทั้งแผนที่ที่ซ้อนกัน รายการและแผนที่อาจมีเครื่องหมายจุลภาคต่อท้ายค่าสุดท้าย

Globs

คุณสมบัติที่รับรายการไฟล์ เช่น srcs สามารถใช้รูปแบบโกลบอลได้ รูปแบบ Glob สามารถมีสัญลักษณ์แทน UNIX * ปกติได้ ตัวอย่างเช่น *.java รูปแบบ Glob ยังสามารถมีสัญลักษณ์ตัวแทน ** เพียงรายการเดียวเป็นองค์ประกอบเส้นทาง ซึ่งตรงกับองค์ประกอบเส้นทางศูนย์หรือมากกว่า ตัวอย่างเช่น 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",
}

ตัวแปรถูกกำหนดขอบเขตไปยังส่วนที่เหลือของไฟล์ที่ประกาศไว้ เช่นเดียวกับไฟล์พิมพ์เขียวย่อยใดๆ ตัวแปรจะไม่เปลี่ยนรูปโดยมีข้อยกเว้นหนึ่งข้อ: สามารถผนวกเข้ากับการมอบหมาย += ได้ แต่ก่อนที่จะมีการอ้างอิงเท่านั้น

ความคิดเห็น

ไฟล์ Android.bp สามารถมี multiline สไตล์ C /* */ และ C++ style single-line // ความคิดเห็น

ผู้ประกอบการ

สตริง รายการสตริง และแผนที่สามารถต่อท้ายได้โดยใช้ตัวดำเนินการ + สามารถสรุปจำนวนเต็มได้โดยใช้ตัวดำเนินการ + การต่อท้ายแผนที่ทำให้เกิดการรวมคีย์ในทั้งสองแผนที่ โดยผนวกค่าของคีย์ใดๆ ที่มีอยู่ในทั้งสองแผนที่

เงื่อนไข

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 ล็ก like ในข้อกำหนดโมดูลที่สร้างไว้ล่วงหน้าจะกำหนดว่าเวอร์ชันใดมีลำดับความสำคัญ โปรดทราบว่าโมดูลที่สร้างไว้ล่วงหน้าบางโมดูลมีชื่อที่ไม่ได้ขึ้นต้นด้วย prebuilt เช่น android_app_import

โมดูลเนมสเปซ

จนกว่า Android จะแปลงจาก Make เป็น Soong โดยสมบูรณ์ การกำหนดค่า Make product ต้องระบุค่า PRODUCT_SOONG_NAMESPACES ค่าควรเป็นรายการเนมสเปซที่คั่นด้วยช่องว่างที่ Soong ส่งออกไปยัง Make เพื่อสร้างโดยคำสั่ง m หลังจากการแปลงของ Android เป็น Soong เสร็จสิ้น รายละเอียดของการเปิดใช้งานเนมสเปซอาจเปลี่ยนแปลงได้

Soong จัดเตรียมความสามารถสำหรับโมดูลในไดเร็กทอรีต่างๆ เพื่อระบุชื่อเดียวกัน ตราบใดที่แต่ละโมดูลได้รับการประกาศภายในเนมสเปซที่แยกจากกัน สามารถประกาศเนมสเปซได้ดังนี้:

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

โปรดทราบว่าเนมสเปซไม่มีคุณสมบัติชื่อ เส้นทางถูกกำหนดโดยอัตโนมัติเป็นชื่อ

แต่ละโมดูล Soong ถูกกำหนดเนมสเปซตามตำแหน่งในแผนผัง โมดูล Soong แต่ละโมดูลจะถือว่าอยู่ในเนมสเปซที่กำหนดโดย soong_namespace ที่พบในไฟล์ Android.bp ในไดเรกทอรีปัจจุบันหรือไดเรกทอรีระดับบนสุดที่ใกล้เคียงที่สุด หากไม่พบโมดูล soong_namespace ดังกล่าว จะถือว่าโมดูลอยู่ในเนมสเปซรูทโดยนัย

นี่คือตัวอย่าง: Soong พยายามแก้ไขการพึ่งพา D ที่ประกาศโดยโมดูล M ในเนมสเปซ N ที่นำเข้าเนมสเปซ I1, I2, I3...

1. จากนั้น ถ้า D เป็นชื่อแบบเต็มของแบบฟอร์ม //namespace:module ระบบจะค้นหาเฉพาะเนมสเปซที่ระบุสำหรับชื่อโมดูลที่ระบุ
2. มิฉะนั้น Soong จะค้นหาโมดูลชื่อ D ที่ประกาศในเนมสเปซ N ก่อน
3. หากไม่มีโมดูลนั้น Soong จะค้นหาโมดูลที่ชื่อ D ในเนมสเปซ I1, I2, I3...
4. สุดท้าย Soong จะดูในเนมสเปซรูต