Aturan
alias
Lihat sumber aturanalias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
Aturan alias
membuat nama lain yang dapat disebut sebagai nama aturan.
Alias hanya berfungsi untuk target "biasa". Secara khusus, package_group
dan test_suite
tidak dapat dialias.
Aliasing dapat sangat membantu pada repositori besar di mana 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 pernyataan visibilitasnya sendiri. Dalam semua aspek lain, perilakunya seperti aturan yang direferensikannya (mis. hanya pengujian pada alias diabaikan; hanya pengujian dari aturan yang direferensikan digunakan sebagai gantinya) dengan beberapa pengecualian kecil:
-
Pengujian tidak akan dijalankan jika aliasnya disebutkan di command line. Untuk menentukan alias yang menjalankan pengujian yang direferensikan, gunakan aturan
test_suite
dengan satu target di atributtests
-nya. -
Saat menentukan grup lingkungan, alias aturan
environment
tidak didukung. Keduanya juga tidak didukung di opsi command line--target_environment
.
Contoh
filegroup( name = "data", srcs = ["data.txt"], ) alias( name = "other", actual = ":data", )
Argumen
Atribut | |
---|---|
name |
Nama; wajib diisi Nama unik untuk target ini. |
actual
|
Label; wajib diisi Target yang dirujuk alias ini. Tidak harus berupa aturan, tetapi juga dapat berupa file input. |
config_setting
Lihat sumber aturanconfig_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
Kode berikut 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
definisi
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 tanda 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
. Perlu diperhatikan bahwa platform akan tetap cocok jika menentukan nilai
batasan tambahan di luar kedua hal tersebut.
config_setting( name = "64bit_glibc_2_25", constraint_values = [ "@platforms//cpu:x86_64", "//example:glibc_2_25", ] )Dalam semua kasus ini, konfigurasi dapat berubah dalam build, misalnya jika target harus di-build untuk platform yang berbeda dari dependensinya. Ini berarti bahwa meskipun
config_setting
tidak cocok dengan tanda command line level teratas, target tersebut mungkin masih cocok
dengan beberapa target build.
Catatan
- Lihat select untuk mengetahui apa yang terjadi jika beberapa
config_setting
cocok dengan status konfigurasi saat ini. - Untuk tanda yang mendukung bentuk singkat (misalnya,
--compilation_mode
vs.-c
), definisivalues
harus menggunakan bentuk lengkap. Nama ini secara otomatis mencocokkan pemanggilan menggunakan salah satu formulir. -
Jika flag menggunakan beberapa nilai (seperti
--copt=-Da --copt=-Db
atau flag Starlark berjenis daftar),values = { "flag": "a" }
cocok jika"a"
ada di mana saja dalam daftar sebenarnya.values = { "myflag": "a,b" }
berfungsi dengan cara yang sama: cocok dengan--myflag=a --myflag=b
,--myflag=a --myflag=b --myflag=c
,--myflag=a,b
, dan--myflag=c,b,a
. Semantik yang tepat bervariasi di antara 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"]
(jadivalues = { "copt": "a,b" }
cocok dengan yang pertama, tetapi tidak cocok dengan yang kedua). Namun,--ios_multi_cpus
(untuk aturan Apple) memang:-ios_multi_cpus=a,b
danios_multi_cpus=a --ios_multi_cpus=b
menghasilkan["a", "b"]
. Lihat definisi flag 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 cara ini menawarkan dukungan yang lebih lemah dan tidak direkomendasikan. Lihat di sini untuk diskusi selengkapnya. - Hindari pengulangan definisi
config_setting
yang identik dalam paket yang berbeda. Sebagai gantinya, referensikanconfig_setting
umum yang ditentukan dalam paket kanonis. values
,define_values
, danconstraint_values
dapat digunakan dalam kombinasi apa pun dalamconfig_setting
yang sama, tetapi setidaknya satu harus ditetapkan untukconfig_setting
tertentu.
Argumen
Atribut | |
---|---|
name |
Nama; wajib diisi Nama unik untuk target ini. |
constraint_values
|
Daftar label; tidak dapat dikonfigurasi; defaultnya adalah constraint_values yang harus ditentukan platform target agar cocok dengan config_setting ini. (Platform eksekusi tidak
dipertimbangkan di sini.) Nilai batasan tambahan apa pun yang dimiliki platform akan diabaikan. Lihat
Atribut Build yang Dapat Dikonfigurasi untuk mengetahui detailnya.
Jika dua |
define_values
|
Kamus: String -> String; tidak dapat dikonfigurasi; defaultnya adalah values , tetapi
khusus untuk flag --define .
Artinya: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) tidak berfungsi karena kunci yang sama ( config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) cocok dengan
|
flag_values
|
Kamus: label -> String; nonconfigurable; defaultnya adalah values , tetapi
untuk
flag build yang ditentukan pengguna.
Ini adalah atribut yang berbeda karena tanda yang ditentukan pengguna direferensikan sebagai label, sementara tanda bawaan direferensikan sebagai string arbitrer. |
values
|
Kamus: String -> String; tidak dapat dikonfigurasi; defaultnya adalah Aturan ini mewarisi konfigurasi target yang dikonfigurasi yang mereferensikannya dalam pernyataan Demi kemudahan, nilai konfigurasi ditetapkan sebagai flag build (tanpa Jika tanda tidak ditetapkan secara eksplisit pada command line, nilai defaultnya akan digunakan.
Jika kunci muncul beberapa kali dalam kamus, hanya instance terakhir yang akan digunakan.
Jika kunci mereferensikan flag yang dapat ditetapkan beberapa kali pada command line (misalnya,
|
grup file
Lihat sumber aturanfilegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
Gunakan filegroup
untuk memberikan nama yang mudah dipahami untuk kumpulan target.
Hal ini kemudian dapat direferensikan dari aturan lain.
Sebaiknya gunakan filegroup
, bukan mereferensikan direktori secara langsung.
Yang kedua tidak berjalan baik karena sistem build tidak memiliki pengetahuan penuh tentang semua file di bawah direktori, sehingga mungkin tidak membangun kembali saat file ini berubah. Jika digabungkan dengan glob, filegroup
dapat memastikan bahwa semua file secara eksplisit diketahui oleh sistem build.
Contoh
Untuk membuat filegroup
yang terdiri dari dua file sumber, lakukan
filegroup( name = "mygroup", srcs = [ "a_file.txt", "some/subdirectory/another_file.txt", ], )
Atau, gunakan glob
untuk memfilter direktori testdata:
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
Atribut | |
---|---|
name |
Nama; wajib diisi Nama unik untuk target ini. |
srcs
|
Daftar label; defaultnya adalah
Hasil ekspresi glob biasa digunakan untuk
nilai atribut |
data
|
Daftar label; defaultnya adalah
Target yang disebutkan dalam atribut |
output_group
|
String; defaultnya adalah "Grup output" adalah kategori artefak output target, yang ditentukan dalam implementasi aturan tersebut. |
{i>genquery<i}
Lihat sumber aturangenquery(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 Blaze 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 akan dilewati dengan peringatan). Cara termudah 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 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
Atribut | |
---|---|
name |
Nama; wajib diisi Nama unik untuk target ini. |
compressed_output
|
Boolean; defaultnya adalah True , output kueri ditulis dalam format file GZIP. Setelan ini dapat digunakan untuk menghindari lonjakan penggunaan memori Bazel jika output kueri diperkirakan berukuran besar. Bazel
sudah secara internal mengompresi output kueri lebih dari 220 byte, apa pun
nilai setelan ini, sehingga menyetel ini ke True tidak dapat mengurangi heap
yang dipertahankan. Namun, cara ini memungkinkan Bazel melewati dekompresi saat menulis file output, yang dapat menghabiskan banyak memori.
|
expression
|
String; wajib diisi Kueri yang akan dieksekusi. Berbeda dengan command line dan tempat lain dalam file BUILD, label di sini diselesaikan sesuai dengan direktori utama ruang kerja. Misalnya, label:b dalam atribut ini dalam file a/BUILD akan merujuk ke //:b target.
|
opts
|
Daftar string; defaultnya adalah bazel query . Beberapa opsi kueri tidak diizinkan di sini: --keep_going , --query_file , --universe_scope , --order_results , dan --order_output . Opsi yang tidak ditentukan di sini akan memiliki nilai defaultnya seperti pada command line bazel query .
|
scope
|
Daftar label; wajib diisi Cakupan kueri. Kueri tidak diizinkan menyentuh target di luar penutupan transitif target ini. |
strict
|
Boolean; defaultnya adalah |
Genrule
Lihat sumber aturangenrule(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 tersebut.
Misalnya, Anda dapat menjalankan satu baris Bash. Namun, jika Anda perlu mengompilasi file C++, tetap
berpegang pada aturan cc_*
yang ada, karena semua tugas yang sulit telah dilakukan
untuk Anda.
Perlu diperhatikan bahwa genrule memerlukan shell untuk menafsirkan argumen perintah. Juga mudah untuk mereferensikan program arbitrer yang tersedia di PATH, tetapi hal ini membuat perintah tersebut bersifat non-hermetik dan mungkin tidak dapat direproduksi. Jika Anda hanya perlu menjalankan satu alat, pertimbangkan untuk menggunakan run_binary sebagai gantinya.
Jangan gunakan genrule untuk menjalankan pengujian. Terdapat 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 info selengkapnya tentang kompilasi silang.
Meskipun genrules berjalan selama build, outputnya sering kali digunakan setelah build, untuk deployment atau pengujian. Pertimbangkan contoh kompilasi kode C untuk mikrokontroler: compiler menerima file sumber C dan menghasilkan kode yang berjalan pada mikrokontroler. Kode yang dihasilkan jelas tidak dapat dijalankan pada CPU yang digunakan untuk membuatnya, tetapi compiler C (jika dikompilasi dari sumber) itu sendiri harus melakukannya.
Sistem build menggunakan konfigurasi exec untuk mendeskripsikan mesin tempat build berjalan dan konfigurasi target untuk mendeskripsikan mesin tempat output build seharusnya dijalankan. Class ini memberikan opsi untuk mengonfigurasi setiap file dan memisahkan file yang terkait ke dalam direktori terpisah untuk menghindari konflik.
Untuk genrules, sistem build memastikan bahwa dependensi dibangun dengan tepat:
srcs
dibangun (jika perlu) untuk konfigurasi target,
tools
dibuat untuk konfigurasi exec, dan outputnya dianggap
untuk konfigurasi target. Kode ini juga menyediakan
variabel "Buat" yang dapat diteruskan oleh perintah genrule ke alat yang sesuai.
Genrule menetapkan tidak ada atribut deps
: aturan bawaan lainnya menggunakan informasi meta yang bergantung pada bahasa yang diteruskan di antara aturan untuk menentukan cara menangani aturan dependen secara otomatis, tetapi tingkat otomatisasi ini tidak mungkin dilakukan untuk genrules. Genrules hanya berfungsi di level file dan runfile.
Kasus Khusus
Kompilasi eksekusi-exec: dalam beberapa kasus, sistem build perlu menjalankan genrules sehingga
output juga dapat dijalankan selama proses build. Misalnya, jika genrule membangun beberapa compiler kustom yang selanjutnya digunakan oleh genrule lain, genrule pertama harus menghasilkan outputnya untuk konfigurasi exec, karena di situlah compiler akan berjalan di genrule lainnya. Dalam hal ini,
sistem build melakukan hal yang benar secara otomatis: sistem membangun srcs
dan
outs
dari genrule pertama untuk konfigurasi exec, bukan konfigurasi
target. Lihat panduan pengguna untuk info
selengkapnya.
Alat JDK & C++: untuk menggunakan alat dari JDK atau paket compiler C++, sistem build menyediakan sekumpulan variabel untuk digunakan. Lihat variabel"Buat" untuk mengetahui detailnya.
Lingkungan Genrule
Perintah genrule dijalankan 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 dalam lingkungan shell pengguna tidak diteruskan ke perintah genrule. Namun, Bazel (tetapi bukan 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 semua 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 bahwa alat yang dijalankan dengan genrule bersifat determenistik dan hermetik. 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 kira tidak sesuai) 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 hard code dan/atau absolut. - Tulis makro Starlark umum jika genrules 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 dan kemampuan pengujian.
- Pastikan bahwa kode keluar menunjukkan keberhasilan atau kegagalan genrule dengan benar.
- Jangan menulis pesan informasi ke {i>stdout<i} atau {i>stderr<i}. Meskipun berguna untuk proses debug, hal ini dapat dengan mudah menjadi derau; genrule yang berhasil harus senyap. Di sisi lain, genrule yang gagal akan memunculkan pesan error yang baik.
$$
evaluates to a$
, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such asls $(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 merujuk genrule dalam aturan lain, Anda dapat menggunakan label genrule atau label tiap 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 akan 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
Atribut | |
---|---|
name |
Nama; wajib diisi Nama unik untuk target ini. Anda dapat merujuk ke aturan ini berdasarkan nama di bagian srcs atau deps dari aturan BUILD lainnya. Jika aturan menghasilkan file sumber, Anda harus menggunakan
atribut srcs .
|
srcs
|
Daftar label; defaultnya adalah
Atribut ini tidak cocok untuk mencantumkan alat yang dieksekusi oleh
Sistem build memastikan prasyarat ini dibangun sebelum menjalankan perintah genrule. Prasyarat di-build menggunakan konfigurasi yang sama dengan permintaan build asli. Nama
file prasyarat ini tersedia untuk perintah sebagai
daftar yang dipisahkan spasi di |
outs
|
Daftar nama file; nonconfigurable; wajib diisi Daftar file yang dibuat oleh aturan ini.File output tidak boleh melewati batas paket. Nama file output ditafsirkan sebagai relatif terhadap paket.
Jika tanda
Perintah genrule diharapkan membuat setiap file output di lokasi yang telah ditentukan.
Lokasi ini tersedia di |
cmd
|
String; defaultnya adalah $(location)
dan variabel"Buat".
cmd_bash , cmd_ps , dan cmd_bat ,
jika tidak ada yang berlaku.
Jika panjang command line melebihi batas platform (64K di Linux/macOS, 8K di Windows),
genrule akan menulis perintah ke skrip dan mengeksekusi skrip tersebut untuk mengatasinya. Ini berlaku untuk semua atribut cmd ( |
cmd_bash
|
String; defaultnya adalah Atribut ini memiliki prioritas lebih tinggi daripada |
cmd_bat
|
String; defaultnya adalah Atribut ini memiliki prioritas lebih tinggi daripada
|
cmd_ps
|
String; defaultnya adalah Atribut ini memiliki prioritas lebih tinggi daripada
Agar Powershell lebih mudah digunakan dan tidak rentan mengalami error, kami menjalankan perintah berikut untuk menyiapkan lingkungan sebelum mengeksekusi perintah Powershell di genrule.
|
executable
|
Boolean; tidak dapat dikonfigurasi; defaultnya adalah
Jika tanda ini disetel ke Benar (True), outputnya adalah file yang dapat dieksekusi dan dapat dijalankan menggunakan
perintah Mendeklarasikan dependensi data untuk file yang dapat dieksekusi yang dihasilkan tidak didukung. |
local
|
Boolean; defaultnya adalah
Jika disetel ke Benar (True), opsi ini akan memaksa
Hal ini sama dengan menyediakan 'local' sebagai tag ( |
message
|
String; defaultnya adalah
Pesan progres yang akan dicetak saat langkah build ini dijalankan. Secara default,
pesannya adalah "Menghasilkan output" (atau sesuatu yang tidak sama), tetapi Anda dapat memberikan
pesan yang lebih spesifik. Gunakan atribut ini, bukan |
output_licenses
|
Jenis lisensi; defaultnya adalah common attributes
|
output_to_bindir
|
Boolean; tidak dapat dikonfigurasi; defaultnya adalah
Jika disetel ke Benar (True), opsi ini akan menyebabkan file output ditulis ke direktori |
tools
|
Daftar label; defaultnya adalah
Sistem build memastikan prasyarat ini dibuat sebelum menjalankan perintah genrule. Prasyarat di-build menggunakan konfigurasi exec, karena alat ini dijalankan sebagai bagian dari build. Jalur setiap target
Setiap |
starlark_doc_extract
Lihat sumber aturanstarlark_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 aturan ini adalah proto biner ModuleInfo
seperti yang ditentukan
dalam
stardoc_output.proto
pada hierarki sumber Bazel.
Target output implisit
name.binaryproto
(output default): Protokol binerModuleInfo
.name.textproto
(hanya dibuat jika diminta secara eksplisit): versi proto teks dariname.binaryproto
.
Peringatan: format output aturan ini tidak dijamin stabil. Protokol ini utamanya ditujukan untuk penggunaan internal oleh Stardoc.
Argumen
Atribut | |
---|---|
name |
Nama; wajib diisi Nama unik untuk target ini. |
deps
|
Daftar label; defaultnya adalah load() oleh
src . Target tersebut harus dalam penggunaan normal menjadi target bzl_library , tetapi aturan starlark_doc_extract tidak menerapkannya, dan menerima semua target yang menyediakan file Starlark dalam DefaultInfo -nya.
Perlu diketahui bahwa file Starlark yang digabungkan harus berupa file dalam hierarki sumber; Bazel tidak dapat |
src
|
Label; wajib diisi File Starlark yang digunakan untuk mengekstrak dokumentasi.Perlu diketahui bahwa ini harus berupa file dalam hierarki sumber; Bazel tidak dapat |
render_main_repo_name
|
Boolean; defaultnya adalah //foo:bar.bzl akan ditampilkan sebagai @main_repo_name//foo:bar.bzl ).
Nama yang akan digunakan untuk repositori utama diperoleh dari Atribut ini harus ditetapkan ke |
symbol_names
|
Daftar string; defaultnya adalah
|
test_suite
Lihat sumber aturantest_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
test_suite
menentukan kumpulan 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 blaze test
mengikuti pengaturan
semacam ini: Untuk panggilan seperti blaze test //some/test:suite
, pertama-tama Blaze
menghitung semua target pengujian yang disertakan secara transitif oleh target //some/test:suite
(kami
menyebut ini "perluasan test_suite"), lalu Blaze akan mem-build dan menguji target tersebut.
Contoh
Paket pengujian untuk menjalankan semua pengujian kecil dalam paket saat ini.
test_suite( name = "small_tests", tags = ["small"], )
Paket pengujian yang menjalankan serangkaian pengujian tertentu:
test_suite( name = "smoke_tests", tests = [ "system_unittest", "public_api_unittest", ], )
Paket pengujian untuk menjalankan semua pengujian dalam paket saat ini yang tidak stabil.
test_suite( name = "non_flaky_test", tags = ["-flaky"], )
Argumen
Atribut | |
---|---|
name |
Nama; wajib diisi Nama unik untuk target ini. |
tags
|
Daftar string; nonconfigurable; defaultnya adalah Tag yang dimulai dengan karakter "-" dianggap sebagai tag negatif. Karakter "-" sebelumnya tidak dianggap sebagai bagian dari tag, sehingga tag suite "-small" cocok dengan ukuran "small" pengujian. Semua tag lainnya dianggap sebagai tag positif. Secara opsional, agar tag positif lebih eksplisit, tag juga dapat dimulai dengan karakter "+", yang tidak akan dievaluasi sebagai bagian dari teks tag. Perbedaan ini hanya membuat perbedaan positif dan negatif lebih mudah dibaca. Hanya aturan pengujian yang cocok dengan semua tag positif dan tidak satu pun tag negatif yang akan disertakan dalam paket pengujian. Perhatikan bahwa ini tidak berarti bahwa pemeriksaan error untuk dependensi pada pengujian yang difilter akan dilewati; dependensi pada pengujian yang dilewati masih harus sah (misalnya, tidak diblokir oleh batasan visibilitas).
Kata kunci tag
Perhatikan bahwa
Jika Anda memerlukan |
tests
|
Daftar label; tidak dapat dikonfigurasi; defaultnya adalah
Semua
Jika atribut |