BUILD file

Laporkan masalah Lihat sumber

Bagian sebelumnya menjelaskan paket, target, dan label, serta grafik dependensi build secara abstrak. Bagian ini menjelaskan sintaksis konkret yang digunakan untuk menetapkan paket.

Pada dasarnya, setiap paket berisi file BUILD yang merupakan program singkat.

File BUILD dievaluasi menggunakan bahasa imperatif, Starlark.

Pernyataan tersebut ditafsirkan sebagai daftar pernyataan yang berurutan.

Secara umum, urutan sangat penting: misalnya, variabel harus ditentukan sebelum digunakan. Namun, sebagian besar file BUILD hanya terdiri dari deklarasi aturan build, dan urutan relatif pernyataan tersebut tidak penting; yang terpenting adalah aturan mana yang dideklarasikan, dan dengan nilai apa, pada saat evaluasi paket selesai.

Saat dijalankan, fungsi aturan build, seperti cc_library, akan membuat target baru dalam grafik. Target ini nantinya dapat dirujuk menggunakan label.

Dalam file BUILD sederhana, deklarasi aturan dapat diurutkan ulang secara bebas tanpa mengubah perilaku.

Untuk mendorong pemisahan yang jelas antara kode dan data, file BUILD tidak boleh berisi definisi fungsi, pernyataan for, atau pernyataan if (tetapi pemahaman daftar dan ekspresi if diizinkan). Fungsi dapat dideklarasikan dalam file .bzl sebagai gantinya. Selain itu, argumen *args dan **kwargs tidak diizinkan dalam file BUILD; sebagai gantinya, cantumkan semua argumen secara eksplisit.

Yang terpenting, program di Starlark tidak dapat melakukan I/O arbitrer. Invarian ini menjadikan interpretasi file BUILD bersifat kemiripan — hanya bergantung pada sekumpulan input yang diketahui, yang penting untuk memastikan bahwa build dapat direproduksi. Untuk mengetahui detail selengkapnya, lihat Hermeticity.

File BUILD hanya boleh ditulis menggunakan karakter ASCII, meskipun secara teknis file tersebut ditafsirkan menggunakan himpunan karakter Latin-1.

Karena file BUILD perlu diperbarui setiap kali dependensi kode yang mendasarinya berubah, file tersebut biasanya dikelola oleh beberapa orang dalam tim. Pembuat file BUILD harus memberikan komentar secara bebas untuk mendokumentasikan peran setiap target build, baik untuk tujuan penggunaan publik maupun tidak, dan untuk mendokumentasikan peran paket itu sendiri.

Memuat ekstensi

Ekstensi Bazel adalah file yang diakhiri dengan .bzl. Gunakan pernyataan load untuk mengimpor simbol dari ekstensi.

load("//foo/bar:file.bzl", "some_library")

Kode ini memuat file foo/bar/file.bzl dan menambahkan simbol some_library ke lingkungan. Cara ini dapat digunakan untuk memuat aturan, fungsi, atau konstanta baru (misalnya, string atau daftar). Beberapa simbol dapat diimpor dengan menggunakan argumen tambahan ke panggilan ke load. Argumen harus berupa literal string (tanpa variabel) dan pernyataan load harus muncul di tingkat teratas — tidak boleh dalam isi fungsi.

Argumen pertama load adalah label yang mengidentifikasi file .bzl. Jika label relatif, masalah tersebut terkait dengan paket (bukan direktori) yang berisi file bzl saat ini. Label relatif dalam pernyataan load harus menggunakan : di awal.

load juga mendukung alias, sehingga Anda dapat menetapkan nama yang berbeda ke simbol yang diimpor.

load("//foo/bar:file.bzl", library_alias = "some_library")

Anda dapat menentukan beberapa alias dalam satu pernyataan load. Selain itu, daftar argumen dapat berisi alias dan nama simbol reguler. Contoh berikut sangat legal (perhatikan kapan harus menggunakan tanda kutip).

load(":my_rules.bzl", "some_rule", nice_alias = "some_other_rule")

Dalam file .bzl, simbol yang dimulai dengan _ tidak diekspor dan tidak dapat dimuat dari file lain.

Anda dapat menggunakan visibilitas pemuatan untuk membatasi pengguna yang dapat memuat file .bzl.

Jenis aturan build

Sebagian besar aturan build terdiri dari keluarga, yang dikelompokkan berdasarkan bahasa. Misalnya, cc_binary, cc_library, dan cc_test adalah aturan build untuk biner, library, dan pengujian C++. Bahasa lain menggunakan skema penamaan yang sama, dengan awalan yang berbeda, seperti java_* untuk Java. Beberapa fungsi ini didokumentasikan dalam Build Encyclopedia, tetapi siapa saja dapat membuat aturan baru.

  • Aturan *_binary mem-build program yang dapat dieksekusi dalam bahasa tertentu. Setelah build, file yang dapat dieksekusi akan berada di hierarki output biner alat build pada nama yang sesuai untuk label aturan, sehingga //my:program akan muncul di (misalnya) $(BINDIR)/my/program.

    Dalam beberapa bahasa, aturan tersebut juga membuat direktori runfile, yang berisi semua file yang disebutkan dalam atribut data milik aturan tersebut, atau aturan apa pun dalam penutupan transitif dependensinya. Kumpulan file ini dikumpulkan di satu tempat untuk memudahkan deployment ke produksi.

  • Aturan *_test adalah spesialisasi dari aturan *_binary, yang digunakan untuk pengujian otomatis. Pengujian hanyalah program yang tidak memberikan hasil jika berhasil.

    Seperti biner, pengujian juga memiliki hierarki runfile, dan file di bawahnya adalah satu-satunya file yang dapat dibuka secara sah saat runtime. Misalnya, program cc_test(name='x', data=['//foo:bar']) dapat membuka dan membaca $TEST_SRCDIR/workspace/foo/bar selama eksekusi. (Setiap bahasa pemrograman memiliki fungsi utilitasnya sendiri untuk mengakses nilai $TEST_SRCDIR, tetapi semuanya setara dengan menggunakan variabel lingkungan secara langsung.) Jika Anda tidak mematuhi aturan, pengujian akan gagal saat dijalankan di host pengujian jarak jauh.

  • Aturan *_library menentukan modul yang dikompilasi secara terpisah dalam bahasa pemrograman yang diberikan. Library dapat bergantung pada library lainnya, dan biner serta pengujian dapat bergantung pada library, dengan perilaku kompilasi terpisah yang diharapkan.

Label Dependensi