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

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

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

ซองคืออะไร

สร้างระบบ Soong เป็นที่รู้จักใน Android 7.0 (ตังเม) ที่จะเปลี่ยนยี่ห้อ มันยกระดับ กะทิ GNU เครื่องมือทำการโคลนและ นินจา องค์ประกอบการสร้างระบบเพื่อเพิ่มความเร็วในการสร้างของ Android

ดู ระบบ Android ทำให้รูปร่าง คำอธิบายใน Android Open Source Project (AOSP) ทั่วไป คำแนะนำ และ สร้างการเปลี่ยนแปลงของระบบสำหรับนักเขียน Android.mk เรียนรู้เกี่ยวกับการปรับเปลี่ยนที่จำเป็นในการปรับตัวจากการทำกับ Soong

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

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

นี่คือการเปรียบเทียบของการกำหนดค่าทำกับ 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,
           },
     },
}

ดู การกำหนดค่ารูปร่างที่เรียบง่าย สำหรับตัวอย่างการกำหนดค่า Soong ทดสอบที่เฉพาะเจาะจง

รูปแบบไฟล์ Android.bp

โดยการออกแบบ Android.bp ไฟล์มีความเรียบง่าย ไม่มีเงื่อนไขหรือคำสั่งควบคุมโฟลว์ ความซับซ้อนทั้งหมดได้รับการจัดการโดยตรรกะการสร้างที่เขียนใน Go เมื่อเป็นไปได้ไวยากรณ์และความหมายของ Android.bp ไฟล์มีความคล้ายคลึงกับ ไฟล์ BUILD Bazel

โมดูล

โมดูลใน Android.bp ไฟล์เริ่มต้นด้วย ประเภทโมดูล ตามด้วยชุดของคุณสมบัติใน name: "value", รูปแบบ:

cc_binary {
    name: "gzip",
    srcs: ["src/test/minigzip.c"],
    shared_libs: ["libz"],
    stl: "none",
}

โมดูลทุกคนจะต้องมี name คุณสมบัติและความคุ้มค่าต้องไม่ซ้ำกันในทุก Android.bp ไฟล์ยกเว้น name ค่าทรัพย์สินใน namespaces และโมดูลที่สร้างไว้ล่วงหน้าซึ่งอาจทำซ้ำ

srcs ระบุสถานที่ให้บริการไฟล์ที่มาใช้ในการสร้างโมดูลเป็นรายการของสตริง คุณสามารถอ้างอิงการส่งออกของโมดูลอื่น ๆ ที่ผลิตไฟล์ที่มาเช่น genrule หรือ filegroup โดยใช้ไวยากรณ์อ้างอิงโมดูล ":<module-name>"

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

ประเภท

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

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

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

Globs

คุณสมบัติที่จะนำรายชื่อของไฟล์เช่น srcs ยังสามารถใช้รูปแบบ glob รูปแบบ 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 ไฟล์สามารถมี C-สไตล์หลาย /* */ และ C ++ รูปแบบบรรทัดเดียว // ความคิดเห็น

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

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

เงื่อนไข

Soong ไม่สนับสนุนเงื่อนไขใน Android.bp ไฟล์ แทนที่จะจัดการความซับซ้อนในกฎการสร้างที่ต้องใช้เงื่อนไขจะได้รับการจัดการใน Go ซึ่งสามารถใช้คุณลักษณะภาษาระดับสูงได้ และสามารถติดตามการพึ่งพาโดยนัยที่นำมาใช้โดยเงื่อนไขได้ เงื่อนไขส่วนใหญ่จะแปลงเป็นคุณสมบัติแผนที่ โดยที่ค่าใดค่าหนึ่งในแผนที่จะถูกเลือกและผนวกเข้ากับคุณสมบัติระดับบนสุด

ตัวอย่างเช่น เพื่อรองรับไฟล์เฉพาะสถาปัตยกรรม:

cc_library {
    ...
    srcs: ["generic.cpp"],
    arch: {
        arm: {
            srcs: ["arm.cpp"],
        },
        x86: {
            srcs: ["x86.cpp"],
        },
    },
}

ตัวจัดรูปแบบ

Soong รวมถึงการจัดรูปแบบเป็นที่ยอมรับสำหรับไฟล์พิมพ์เขียวคล้ายกับ 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

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

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

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

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

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

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

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

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