Mengonversi dari Make ke Soong

Sebelum rilis Android 7.0, Android menggunakan GNU Make secara eksklusif untuk menjelaskan dan menjalankan aturan build-nya. Sistem build Make didukung dan digunakan secara luas, tetapi pada skala Android menjadi lambat, rentan error, tidak skalabel, dan sulit diuji. Sistem build Soong memberikan fleksibilitas yang diperlukan untuk build Android.

Karena alasan ini, developer platform diharapkan beralih dari Make dan mengadopsi Soong sesegera mungkin. Kirim pertanyaan ke grup Google android-building untuk menerima dukungan.

Apa yang dimaksud dengan Soong?

Sistem build Soong diperkenalkan di Android 7.0 (Nougat) untuk menggantikan Make. Rilis ini memanfaatkan alat clone Kati GNU Make clone dan komponen sistem build Ninja untuk mempercepat build Android.

Lihat deskripsi Sistem Build Android Make di Proyek Open Source Android (AOSP) untuk mengetahui petunjuk umum dan Perubahan Sistem Build untuk Penulis Android.mk guna mempelajari modifikasi yang diperlukan untuk beradaptasi dari Make ke Soong.

Lihat entri terkait build dalam glosarium untuk definisi istilah utama dan file referensi Soong untuk mengetahui detail selengkapnya.

Perbandingan Make dan Soong

Berikut adalah perbandingan konfigurasi Make dengan Soong yang mencapai hal yang sama dalam file konfigurasi Soong (Blueprint atau .bp).

Membuat contoh

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)

Contoh Soong

cc_library_shared {
     name: "libxmlrpc++",

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

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

Untuk contoh konfigurasi Soong khusus pengujian, lihat Konfigurasi Build Sederhana.

Untuk penjelasan kolom dalam file Android.bp, lihat format file Android.bp.

Modul khusus

Beberapa grup modul khusus memiliki karakteristik unik.

Modul default

Modul default dapat digunakan untuk mengulangi properti yang sama di beberapa modul. Contoh:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

Modul bawaan

Beberapa jenis modul bawaan memungkinkan modul memiliki nama yang sama dengan modul berbasis sumbernya. Misalnya, mungkin ada cc_prebuilt_binary bernama foo jika sudah ada cc_binary dengan nama yang sama. Dengan demikian, developer memiliki fleksibilitas untuk memilih versi yang akan disertakan dalam produk akhir. Jika konfigurasi build berisi kedua versi, nilai flag prefer dalam definisi modul bawaan akan menentukan versi mana yang memiliki prioritas. Perlu diperhatikan bahwa beberapa modul bawaan memiliki nama yang tidak diawali dengan prebuilt, seperti android_app_import.

Modul namespace

Hingga Android sepenuhnya mengonversi dari Make ke Soong, konfigurasi produk Make harus menentukan nilai PRODUCT_SOONG_NAMESPACES. Nilainya harus berupa daftar namespace yang dipisahkan spasi yang diekspor Soong ke Make untuk di-build oleh perintah m. Setelah konversi Android ke Soong selesai, detail pengaktifan namespace dapat berubah.

Soong memberikan kemampuan bagi modul di berbagai direktori untuk menentukan nama yang sama, selama setiap modul dideklarasikan dalam namespace terpisah. Namespace dapat dideklarasikan seperti ini:

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

Perlu diperhatikan bahwa namespace tidak memiliki properti nama; jalurnya secara otomatis ditetapkan sebagai namanya.

Setiap modul Soong diberi namespace berdasarkan lokasinya dalam hierarki. Setiap modul Soong dianggap berada dalam namespace yang ditentukan oleh soong_namespace yang ditemukan dalam file Android.bp di direktori saat ini atau direktori ancestor terdekat. Jika modul soong_namespace tidak ditemukan, modul dianggap berada dalam namespace root implisit.

Berikut ini contohnya: Soong mencoba menyelesaikan dependensi D yang dideklarasikan oleh modul M dalam namespace N yang mengimpor namespace I1, I2, I3...

1. Kemudian, jika D adalah nama yang sepenuhnya memenuhi syarat dalam bentuk //namespace:module, hanya namespace yang ditentukan yang akan ditelusuri untuk nama modul yang ditentukan.
2. Jika tidak, Soong akan terlebih dahulu mencari modul bernama D yang dideklarasikan di namespace N.
3. Jika modul tersebut tidak ada, Soong akan mencari modul bernama D di namespace I1, I2, I3…
4. Terakhir, Soong mencari di namespace root.