Format file Android.bp

Secara desain, file Android.bp sangat mudah. Tidak berisi pernyataan kondisional atau alur kontrol; semua kompleksitas ditangani oleh logika build yang ditulis dalam Go.

Modul

Modul dalam file Android.bp dimulai dengan jenis modul diikuti dengan serangkaian properti dalam format name: "value",:

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

Setiap modul harus memiliki properti name, dan nilainya harus unik di semua file Android.bp, kecuali untuk nilai properti name di namespace dan modul bawaan, yang mungkin berulang.

Properti srcs menentukan file sumber yang digunakan untuk membangun modul, sebagai daftar string. Anda dapat mereferensikan output modul lain yang menghasilkan file sumber, seperti genrule atau filegroup, dengan menggunakan sintaksis referensi modul ":<module-name>".

Untuk mengetahui daftar jenis modul yang valid dan propertinya, lihat Referensi Modul Soong.

Jenis

Variabel dan properti memiliki jenis yang ditentukan dengan kuat, dengan variabel yang bersifat dinamis berdasarkan penugasan pertama, dan properti yang ditetapkan secara statis oleh jenis modul. Jenis yang didukung adalah:

  • Boolean (true atau false)
  • Bilangan bulat (int)
  • String ("string")
  • Daftar string (["string1", "string2"])
  • Peta ({key1: "value1", key2: ["value2"]})

Peta dapat berisi nilai dari jenis apa pun, termasuk peta bertingkat. Daftar dan peta mungkin memiliki koma di akhir setelah nilai terakhir.

Gumpalan

Properti yang mengambil daftar file, seperti srcs, juga dapat mengambil pola glob. Pola glob dapat berisi karakter pengganti UNIX normal *, misalnya *.java. Pola glob juga dapat berisi satu karakter pengganti ** sebagai elemen jalur, yang cocok dengan nol atau beberapa elemen jalur. Misalnya, java/**/*.java cocok dengan pola java/Main.java dan java/com/android/Main.java.

Variabel

File Android.bp dapat berisi penetapan variabel tingkat teratas:

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

Variabel dicakup ke bagian file yang dideklarasikan, serta file Blueprint turunan. Variabel tidak dapat diubah dengan satu pengecualian: variabel dapat ditambahkan dengan penetapan +=, tetapi hanya sebelum variabel dirujuk.

Komentar

File Android.bp dapat berisi komentar multiline gaya C /* */ dan komentar satu baris gaya C++ //.

Operator

String, daftar string, dan peta dapat ditambahkan menggunakan operator +. Bilangan bulat dapat dijumlahkan menggunakan operator +. Menambahkan peta akan menghasilkan gabungan kunci di kedua peta, dengan menambahkan nilai kunci yang ada di kedua peta.

Modul default

Developer dapat menggunakan modul default untuk mengulang 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, ada cc_prebuilt_binary bernama foo padahal sudah ada cc_binary dengan nama yang sama. Hal ini memberi developer fleksibilitas untuk memilih versi yang akan disertakan dalam produk akhir mereka. Jika konfigurasi build berisi kedua versi, nilai flag prefer dalam definisi modul bawaan akan menentukan versi mana yang diprioritaskan. Perhatikan bahwa beberapa modul bawaan memiliki nama yang tidak diawali dengan prebuilt, seperti android_app_import.

Modul namespace

Hingga Android sepenuhnya dikonversi 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 dibangun oleh perintah m. Setelah konversi Android ke Soong selesai, detail pengaktifan namespace dapat berubah.

Soong memberikan kemampuan bagi modul di direktori yang berbeda untuk menentukan nama yang sama, selama setiap modul dideklarasikan dalam namespace terpisah. Developer dapat mendeklarasikan namespace:

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

Perhatikan bahwa namespace tidak memiliki properti name; jalur namespace otomatis ditetapkan sebagai namanya.

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

Berikut contohnya: Soong mencoba menyelesaikan dependensi D yang dideklarasikan oleh modul M di 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. Soong mencari di namespace root.

Bersyarat

Soong tidak mendukung kondisi dalam file Android.bp. Sebagai gantinya, kompleksitas dalam aturan build yang memerlukan kondisi ditangani di Go, tempat fitur bahasa tingkat tinggi dapat digunakan, dan dependensi implisit yang diperkenalkan oleh kondisi dapat dilacak. Sebagian besar kondisi dikonversi menjadi properti peta, dengan salah satu nilai dalam peta dipilih dan ditambahkan ke properti tingkat teratas.

Misalnya, untuk mendukung file khusus arsitektur:

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

Pemformat

Soong menyertakan pemformat kanonis untuk file Blueprint, mirip dengan gofmt. Untuk memformat ulang semua file Android.bp secara rekursif di direktori saat ini, jalankan:

bpfmt -w .

Format kanonis mencakup indentasi empat spasi, baris baru setelah setiap elemen dari daftar multielemen, dan koma di akhir daftar dan peta.