Peraturan Umum

Aturan

• alias
• config_setting
• filegroup
• genquery
• genrule
• starlark_doc_extract
• test_suite

alias

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

Aturan alias membuat nama lain yang dapat digunakan untuk merujuk aturan.

Alias hanya berfungsi untuk target "reguler". Secara khusus, package_group dan test_suite tidak dapat diberi alias.

Aliasing dapat membantu di repositori besar, tempat mengganti nama target akan memerlukan perubahan pada banyak file. Anda juga dapat menggunakan aturan alias untuk menyimpan panggilan fungsi select jika ingin menggunakan kembali logika tersebut untuk beberapa target.

Aturan alias memiliki deklarasi visibilitasnya sendiri. Dalam hal lainnya, alias ini berperilaku seperti aturan yang dirujuknya (misalnya, testonly di alias diabaikan; sifat testonly dari aturan yang dirujuk akan digunakan) dengan beberapa pengecualian kecil:

• Pengujian tidak akan dijalankan jika aliasnya disebutkan di command line. Untuk menentukan alias yang menjalankan pengujian yang dirujuk, gunakan aturan test_suite dengan satu target dalam atribut tests nya.
• Saat menentukan grup lingkungan, alias ke aturan environment tidak didukung. Opsi tersebut juga tidak didukung dalam opsi command line --target_environment.

Contoh

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

Argumen

config_setting

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

Mencocokkan status konfigurasi yang diharapkan (dinyatakan sebagai flag build atau batasan platform) untuk tujuan memicu atribut yang dapat dikonfigurasi. Lihat select untuk mengetahui cara menggunakan aturan ini dan Atribut yang dapat dikonfigurasi untuk mengetahui ringkasan fitur umum.

Contoh

Berikut ini cocok dengan build apa pun yang menetapkan --compilation_mode=opt atau -c opt (baik secara eksplisit di command line maupun secara implisit dari file .bazelrc):

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

Berikut ini cocok dengan build apa pun yang menargetkan ARM dan menerapkan FOO=bar penetapan kustom (misalnya, bazel build --cpu=arm --define FOO=bar ...):

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

Berikut ini cocok dengan build apa pun yang menetapkan flag yang ditentukan pengguna --//custom_flags:foo=1 (baik secara eksplisit di command line maupun secara implisit dari file .bazelrc):

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

Berikut ini cocok dengan build apa pun yang menargetkan platform dengan arsitektur x86_64 dan glibc versi 2.25, dengan asumsi keberadaan constraint_value dengan label //example:glibc_2_25. Perhatikan bahwa platform masih cocok jika menentukan nilai batasan tambahan di luar dua nilai ini.

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  

Catatan

• Lihat select untuk mengetahui apa yang terjadi saat beberapa config_setting cocok dengan status konfigurasi saat ini.
• Untuk flag yang mendukung bentuk singkatan (misalnya --compilation_mode vs. -c), definisi values harus menggunakan bentuk lengkap. Ini secara otomatis mencocokkan pemanggilan menggunakan salah satu bentuk.
• Jika flag menggunakan beberapa nilai (seperti --copt=-Da --copt=-Db atau flag Starlark berjenis daftar), values = { "flag": "a" } akan cocok jika "a" ada di mana saja dalam daftar sebenarnya.

  values = { "myflag": "a,b" } berfungsi dengan cara yang sama: ini cocok dengan --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c, --myflag=a,b, dan --myflag=c,b,a. Semantik yang tepat bervariasi antar-tanda. Misalnya, --copt tidak mendukung beberapa nilai dalam instance yang sama: --copt=a,b menghasilkan ["a,b"], sedangkan --copt=a --copt=b menghasilkan ["a", "b"] (sehingga values = { "copt": "a,b" } cocok dengan yang pertama, tetapi tidak dengan yang kedua). Namun, --ios_multi_cpus (untuk aturan Apple) memilikinya: -ios_multi_cpus=a,b dan ios_multi_cpus=a --ios_multi_cpus=b menghasilkan ["a", "b"]. Periksa definisi tanda dan uji kondisi Anda dengan cermat untuk memverifikasi ekspektasi yang tepat.

• Jika Anda perlu menentukan kondisi yang tidak dimodelkan oleh tanda build bawaan, gunakan Tanda yang ditentukan Starlark. Anda juga dapat menggunakan --define, tetapi hal ini menawarkan dukungan yang lebih lemah dan tidak direkomendasikan. Lihat di sini untuk diskusi lebih lanjut.
• Hindari mengulangi definisi config_setting yang identik dalam paket yang berbeda. Sebagai gantinya, referensikan config_setting umum yang ditentukan dalam paket kanonis.
• values, define_values, dan constraint_values dapat digunakan dalam kombinasi apa pun di config_setting yang sama, tetapi setidaknya satu harus ditetapkan untuk config_setting tertentu.

Argumen

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

grup file

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

Gunakan filegroup untuk mengumpulkan output dari kumpulan target dalam satu label.

filegroup bukanlah pengganti target listingan pada command line atau dalam atribut aturan lain, karena target memiliki banyak properti selain outputnya, yang tidak dikumpulkan dengan cara yang sama. Namun, atribut ini masih berguna dalam beberapa kasus, misalnya, dalam atribut srcs dari genrule, atau atribut data dari aturan *_binary.

Sebaiknya gunakan filegroup, bukan mereferensikan direktori secara langsung. Mereferensikan direktori secara langsung tidak dianjurkan karena sistem build tidak memiliki pengetahuan lengkap tentang semua file di bawah direktori, sehingga mungkin tidak membangun ulang saat file ini berubah. Jika digabungkan dengan glob, filegroup dapat memastikan bahwa semua file diketahui secara eksplisit oleh sistem build.

Contoh

Untuk membuat filegroup yang terdiri dari dua file sumber, lakukan

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "//a/library:target",
        "//a/binary:target",
    ],
)

Atau, gunakan glob untuk meng-crawl direktori testdata sepenuhnya:

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

Untuk memanfaatkan definisi ini, referensikan filegroup dengan label dari aturan apa pun:

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

Argumen

genquery

genquery(name, deps, data, compatible_with, compressed_output, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery() menjalankan kueri yang ditentukan dalam bahasa kueri Bazel dan membuang hasilnya ke dalam file.

Agar build tetap konsisten, kueri hanya diizinkan membuka penutupan transitif target yang ditentukan dalam atribut scope. Kueri yang melanggar aturan ini akan gagal selama eksekusi jika strict tidak ditentukan atau benar (jika strict salah, target di luar cakupan hanya akan dilewati dengan peringatan). Cara paling mudah untuk memastikan hal ini tidak terjadi adalah dengan menyebutkan label yang sama dalam cakupan seperti dalam ekspresi kueri.

Satu-satunya perbedaan antara kueri yang diizinkan di sini dan di command line adalah kueri yang berisi spesifikasi target karakter pengganti (misalnya, //pkg:* atau //pkg:all) tidak diizinkan di sini. Alasannya ada dua: pertama, karena genquery harus menentukan cakupan untuk mencegah target di luar penutupan transitif kueri agar dapat memengaruhi outputnya; dan kedua, karena file BUILD tidak mendukung dependensi karakter pengganti (misalnya, deps=["//a/..."] tidak diizinkan).

Output genquery diurutkan secara leksikografis untuk menerapkan output deterministik, dengan pengecualian --output=graph|minrank|maxrank atau jika somepath digunakan sebagai fungsi level atas.

Nama file output adalah nama aturan.

Contoh

Contoh ini menulis daftar label dalam penutupan transitif target yang ditentukan ke file.

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

Argumen

genrule

genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

genrule menghasilkan satu atau beberapa file menggunakan perintah Bash yang ditentukan pengguna.

Genrules adalah aturan build generik yang dapat Anda gunakan jika tidak ada aturan khusus untuk tugas. Misalnya, Anda dapat menjalankan satu baris Bash. Namun, jika Anda perlu mengompilasi file C++, ikuti aturan cc_* yang ada, karena semua pekerjaan berat telah dilakukan untuk Anda.

Perhatikan bahwa genrule memerlukan shell untuk menafsirkan argumen perintah. Mereferensikan program arbitrer yang tersedia di PATH juga mudah, tetapi hal ini membuat perintah menjadi tidak hermetis dan mungkin tidak dapat direproduksi. Jika Anda hanya perlu menjalankan satu alat, sebaiknya gunakan run_binary sebagai gantinya.

Seperti tindakan lainnya, tindakan yang dibuat oleh genrules tidak boleh mengasumsikan apa pun tentang direktori kerja mereka; semua jaminan Bazel adalah bahwa input yang dideklarasikan akan tersedia di jalur yang ditampilkan $(location) untuk labelnya. Misalnya, jika tindakan dijalankan di sandbox atau dari jarak jauh, implementasi sandbox atau eksekusi jarak jauh akan menentukan direktori kerja. Jika dijalankan secara langsung (menggunakan strategi standalone), direktori kerja akan menjadi root eksekusi, yaitu hasil bazel info execution_root.

Jangan gunakan genrule untuk menjalankan pengujian. Ada dispensasi khusus untuk pengujian dan hasil pengujian, termasuk kebijakan penyimpanan dalam cache dan variabel lingkungan. Pengujian umumnya perlu dijalankan setelah build selesai dan pada arsitektur target, sedangkan genrules dijalankan selama build dan pada arsitektur exec (keduanya mungkin berbeda). Jika Anda memerlukan aturan pengujian tujuan umum, gunakan sh_test.

Pertimbangan Kompilasi Silang

Lihat panduan pengguna untuk mengetahui info selengkapnya tentang kompilasi silang.

Saat genrules berjalan selama build, output-nya sering digunakan setelah build, untuk deployment atau pengujian. Pertimbangkan contoh kompilasi kode C untuk pengontrol mikro: compiler menerima file sumber C dan menghasilkan kode yang berjalan di pengontrol mikro. Kode yang dihasilkan jelas tidak dapat berjalan di CPU yang digunakan untuk mem-build-nya, tetapi compiler C (jika dikompilasi dari sumber) itu sendiri harus.

Sistem build menggunakan konfigurasi exec untuk mendeskripsikan mesin tempat build dijalankan dan konfigurasi target untuk mendeskripsikan mesin tempat output build seharusnya dijalankan. Alat ini menyediakan opsi untuk mengonfigurasi setiap opsi tersebut dan memisahkan file yang sesuai ke dalam direktori terpisah untuk menghindari konflik.

Untuk genrules, sistem build memastikan bahwa dependensi di-build dengan benar: srcs di-build (jika diperlukan) untuk konfigurasi target, tools di-build untuk konfigurasi exec, dan output dianggap untuk konfigurasi target. Kode ini juga menyediakan variabel "Buat" yang dapat diteruskan oleh perintah genrule ke alat yang sesuai.

Genrule sengaja tidak menentukan atribut deps: aturan bawaan lainnya menggunakan informasi meta dependen bahasa yang diteruskan di antara aturan untuk secara otomatis menentukan cara menangani aturan dependen, tetapi tingkat otomatisasi ini tidak dapat dilakukan untuk genrule. Genrules hanya berfungsi di level file dan runfile.

Kasus Khusus

Kompilasi exec-exec: dalam beberapa kasus, sistem build perlu menjalankan genrules sehingga output juga dapat dieksekusi selama build. Misalnya, jika genrule mem-build beberapa compiler kustom yang kemudian digunakan oleh genrule lain, genrule pertama harus menghasilkan outputnya untuk konfigurasi exec, karena di sana compiler akan berjalan di genrule lain. Dalam hal ini, sistem build melakukan hal yang benar secara otomatis: sistem build membuat srcs dan outs dari genrule pertama untuk konfigurasi exec, bukan konfigurasi target. Lihat panduan pengguna untuk info selengkapnya.

JDK & Alat C++: untuk menggunakan alat dari JDK atau suite compiler C++, sistem build menyediakan serangkaian variabel yang akan digunakan. Lihat Variabel"Make" untuk mengetahui detailnya.

Lingkungan Genrule

Perintah genrule dieksekusi oleh shell Bash yang dikonfigurasi untuk gagal saat perintah atau pipeline gagal, menggunakan set -e -o pipefail.

Alat build menjalankan perintah Bash dalam lingkungan proses bersih yang hanya menentukan variabel inti seperti PATH, PWD, TMPDIR, dan beberapa variabel lainnya. Untuk memastikan bahwa build dapat direproduksi, sebagian besar variabel yang ditentukan di lingkungan shell pengguna tidak diteruskan ke perintah genrule. Namun, Bazel (tetapi tidak Blaze) meneruskan nilai variabel lingkungan PATH pengguna. Setiap perubahan pada nilai PATH akan menyebabkan Bazel mengeksekusi ulang perintah pada build berikutnya.

Perintah genrule tidak boleh mengakses jaringan, kecuali untuk menghubungkan proses yang merupakan turunan dari perintah itu sendiri, meskipun saat ini tindakan tersebut tidak diterapkan.

Sistem build akan otomatis menghapus file output yang ada, tetapi membuat direktori induk yang diperlukan sebelum menjalankan genrule. Alat ini juga menghapus file output jika terjadi kegagalan.

Saran Umum

• Pastikan alat yang dijalankan oleh genrule bersifat deterministik dan hermetis. Komponen tersebut tidak boleh menulis stempel waktu ke outputnya, dan harus menggunakan pengurutan yang stabil untuk kumpulan dan peta, serta hanya menulis jalur file relatif ke output, tanpa jalur absolut. Tidak mengikuti aturan ini akan menyebabkan perilaku build yang tidak terduga (Bazel tidak mem-build ulang genrule yang Anda harapkan) dan menurunkan performa cache.
• Gunakan $(location) secara ekstensif, untuk output, alat, dan sumber. Karena pemisahan file output untuk konfigurasi yang berbeda, genrules tidak dapat mengandalkan jalur absolut dan/atau hard code.
• Tulis makro Starlark umum jika genrule yang sama atau sangat mirip digunakan di beberapa tempat. Jika genrule bersifat kompleks, pertimbangkan untuk menerapkannya dalam skrip atau sebagai aturan Starlark. Hal ini meningkatkan keterbacaan serta kemudahan pengujian.
• Pastikan kode keluar menunjukkan keberhasilan atau kegagalan genrule dengan benar.
• Jangan menulis pesan informasi ke stdout atau stderr. Meskipun berguna untuk proses debug, hal ini dapat dengan mudah menjadi derau; genrule yang berhasil akan diam. Di sisi lain, genrule yang gagal akan menampilkan pesan error yang baik.
• $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
• Hindari membuat symlink dan direktori. Bazel tidak menyalin struktur direktori/symlink yang dibuat oleh genrules dan pemeriksaan dependensinya terhadap direktori tidak berfungsi dengan benar.
• Saat mereferensikan genrule dalam aturan lain, Anda dapat menggunakan label genrule atau label setiap file output. Terkadang pendekatan yang satu lebih mudah dibaca, terkadang yang lainnya: mereferensikan output berdasarkan nama dalam srcs aturan yang memakai akan menghindari pengambilan output lain dari genrule secara tidak sengaja, tetapi bisa melelahkan jika genrule menghasilkan banyak output.

Contoh

Contoh ini menghasilkan foo.h. Tidak ada sumber, karena perintah tidak mengambil input apa pun. "Biner" yang dijalankan oleh perintah adalah skrip perl dalam paket yang sama dengan genrule.

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

Contoh berikut menunjukkan cara menggunakan filegroup dan output genrule lainnya. Perlu diperhatikan bahwa menggunakan $(SRCS), bukan perintah $(location) eksplisit, juga dapat berfungsi; contoh ini menggunakan perintah yang disebut terakhir untuk demonstrasi.

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

Argumen

starlark_doc_extract

starlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)

starlark_doc_extract() mengekstrak dokumentasi untuk aturan, fungsi (termasuk makro), aspek, dan penyedia yang ditentukan atau diekspor ulang dalam file .bzl atau .scl tertentu. Output dari aturan ini adalah proto biner ModuleInfo seperti yang ditentukan dalam stardoc_output.proto pada hierarki sumber Bazel.

Target output implisit

• name.binaryproto (output default): Proto biner ModuleInfo.
• name.textproto (hanya dibuat jika diminta secara eksplisit): versi proto teks name.binaryproto.

Peringatan: format output aturan ini tidak dijamin stabil. Protokol ini utamanya ditujukan untuk penggunaan internal oleh Stardoc.

Argumen

test_suite

test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite menentukan serangkaian pengujian yang dianggap "berguna" bagi manusia. Hal ini memungkinkan project untuk menentukan serangkaian pengujian, seperti "pengujian yang harus Anda jalankan sebelum check in", "stres tes project kami", atau "semua pengujian kecil". Perintah bazel test mengikuti pengaturan semacam ini: Untuk panggilan seperti bazel test //some/test:suite, pertama-tama Bazel menghitung semua target pengujian yang disertakan secara transitif oleh target //some/test:suite (kami menyebut ini "perluasan test_suite"), lalu Bazel akan mem-build dan menguji target tersebut.

Contoh

Test suite untuk menjalankan semua pengujian kecil dalam paket saat ini.

test_suite(
    name = "small_tests",
    tags = ["small"],
)

Rangkaian pengujian yang menjalankan serangkaian pengujian yang ditentukan:

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

Rangkaian pengujian untuk menjalankan semua pengujian dalam paket saat ini yang tidak bermasalah.

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

Argumen