- Penggunaan
- Variabel standar
- Variabel genrule yang telah ditetapkan
- Variabel jalur sumber/output yang telah ditentukan sebelumnya
- Variabel kustom
"Buat" variabel adalah kelas khusus dari variabel string yang dapat diperluas yang tersedia ke atribut yang ditandai sebagai "Subjek 'Buat variabel' substitusi".
Ini dapat digunakan, misalnya, untuk memasukkan jalur toolchain tertentu ke dalam tindakan build buatan pengguna.
Bazel menyediakan kedua variabel standar, yang tersedia untuk semua target, dan variabel kustom, yang ditentukan dalam target dependensi dan hanya tersedia untuk target yang bergantung padanya.
Alasan digunakannya istilah "Buat" bersifat historis: sintaks dan semantik dari variabel ini awalnya dimaksudkan agar cocok dengan GNU Kreasi.
Gunakan
Atribut ditandai sebagai "Subjek ke 'Buat variabel' substitusi" dapat
merujuk pada "{i>Make<i}" variabel FOO
sebagai berikut:
my_attr = "prefix $(FOO) suffix"
Dengan kata lain, setiap substring yang cocok dengan $(FOO)
akan diperluas
ke nilai FOO
. Jika nilai tersebut adalah "bar"
, nilai akhir
string menjadi:
my_attr = "prefix bar suffix"
Jika FOO
tidak sesuai dengan variabel yang diketahui oleh
target, Bazel gagal dengan error.
"Buat" variabel yang namanya berupa simbol bukan huruf, seperti
@
, juga dapat direferensikan hanya menggunakan tanda dolar, tanpa
tanda kurung. Contoh:
my_attr = "prefix $@ suffix"
Untuk menulis $
sebagai literal string (yaitu untuk mencegah variabel
ekspansi), tulis $$
.
Variabel yang telah ditetapkan
"Buat" standar variabel dapat direferensikan oleh atribut apa pun yang ditandai sebagai "Bergantung pada 'Buat variabel' substitusi" pada target apa pun.
Untuk melihat daftar variabel ini dan nilainya untuk kumpulan build tertentu opsi, jalankan
bazel info --show_make_env [build options]
dan lihat garis {i>output<i} teratas dengan huruf kapital.
Lihat contoh variabel yang telah ditetapkan.
Variabel opsi Toolchain
COMPILATION_MODE
:fastbuild
,dbg
, atauopt
. (selengkapnya detail)
Variabel jalur
-
BINDIR
: Dasar hierarki biner yang dihasilkan untuk target tentang arsitektur ini.Perhatikan bahwa pohon yang berbeda dapat digunakan untuk program yang berjalan selama membangun arsitektur {i>host<i}, untuk mendukung kompilasi silang.
Jika Anda ingin menjalankan alat dari dalam
genrule
, metode cara yang disarankan untuk mendapatkan jalurnya adalah$(execpath toolname)
, tempat toolname harus dicantumkan di kolomgenrule
tools
. GENDIR
: Basis hierarki kode yang dihasilkan untuk arsitektur target.
Variabel arsitektur mesin
-
TARGET_CPU
: CPU arsitektur target, misalnyak8
.
Variabel genrule yang telah ditetapkan
Berikut ini tersedia khusus untuk genrule
cmd
dan merupakan
penting untuk membuat atribut itu berfungsi.
Lihat contoh variabel genrule yang telah ditetapkan sebelumnya.
OUTS
: Daftarouts
genrule
. Jika Anda memiliki hanya satu file output, Anda juga dapat menggunakan$@
.-
SRCS
: Daftarsrcs
genrule
(atau lebih secara tepat: nama jalur file yang sesuai dengan label dalamsrcs
). Jika hanya memiliki satu file sumber, Anda juga dapat menggunakan$<
. -
<
:SRCS
, jika berupa file tunggal. Pemicu lain mengalami error build. -
@
:OUTS
, jika berupa file tunggal. Else memicu error build. -
RULEDIR
: Direktori output target, yaitu direktori yang sesuai dengan nama paket yang berisi informasi di bawah pohongenfiles
ataubin
. Sebagai//my/pkg:my_genrule
ini selalu berakhir denganmy/pkg
, meskipun output//my/pkg:my_genrule
ada di subdirektori. -
@D
: Direktori output. Jika outs memiliki satu entri, ini akan memperluas ke direktori yang berisi file tersebut. Jika terdapat beberapa entri, ini akan meluas ke direktori {i>root<i} paket di Hierarkigenfiles
, meskipun semua file output berada di lokasi yang sama subdirektori.Catatan: Gunakan
RULEDIR
daripada@D
karenaRULEDIR
memiliki semantik yang lebih sederhana dan berperilaku dengan cara yang sama terlepas dari jumlah file {i>output<i}.Jika genrule perlu menghasilkan file perantara sementara (mungkin sebagai akibat menggunakan beberapa alat lain seperti kompiler), alat itu harus mencoba tuliskan ke
@D
(meskipun/tmp
juga akan dapat ditulis) dan menghapusnya sebelum selesai.Hindari penulisan ke direktori yang berisi input. Fitur tersebut mungkin aktif sistem file hanya-baca. Bahkan jika tidak, melakukan hal itu akan membuang pohon sumber.
Variabel jalur sumber/output yang telah ditentukan sebelumnya
Variabel yang telah ditetapkan execpath
, execpaths
,
rootpath
, rootpaths
, location
, dan
locations
mengambil parameter label (misalnya $(execpath
//foo:bar)
) dan menggantikan jalur file yang ditunjukkan oleh label tersebut.
Untuk file sumber, ini adalah jalur yang terkait dengan root ruang kerja Anda. Untuk file yang merupakan output aturan, ini adalah jalur output file (lihat penjelasan file output di bawah).
Lihat contoh variabel jalur yang telah ditetapkan sebelumnya.
-
execpath
: Menunjukkan jalur di bawah execroot tempat Bazel menjalankan tindakan build.Pada contoh di atas, Bazel menjalankan semua tindakan build di direktori yang ditautkan oleh symlink
bazel-myproject
di root ruang kerja Anda. Tujuan file sumberempty.source
ditautkan di jalurbazel-myproject/testapp/empty.source
. Jadi jalur exec-nya (yang adalah subjalur di bawah root) adalahtestapp/empty.source
. Ini adalah jalur yang dapat digunakan tindakan build untuk menemukan file.File output ditahapkan dengan cara serupa, tetapi juga diawali dengan subjalur
bazel-out/cpu-compilation_mode/bin
(atau untuk output alat:bazel-out/cpu-opt-exec-hash/bin
). Dalam contoh di atas,//testapp:app
adalah alat karena muncul di Atributtools
show_app_output
. Jadi, file output-nya,app
, ditulis kebazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app
. Jadi, jalur exec adalahbazel-out/cpu-opt-exec-hash/bin/testapp/app
. Awalan ekstra ini memungkinkan untuk membangun target yang sama untuk, katakanlah, dua CPU berbeda di {i>build<i} yang sama tanpa hasilnya mengacaukan satu sama lain.Label yang diteruskan ke variabel ini harus merepresentasikan satu file. Sebagai label yang mewakili file sumber, ini secara otomatis benar. Untuk label aturan yang merepresentasikan, aturan harus menghasilkan satu {i>output<i}. Jika ini adalah false atau label salah format, build akan gagal dengan error.
-
rootpath
: Menunjukkan jalur yang dapat digunakan biner yang dibuat untuk menemukan dependensi pada runtime yang terkait dengan subdirektori runfile-nya yang sesuai dengan repositori utama. Catatan: Ini hanya berfungsi jika--enable_runfiles
diaktifkan, tetapi hal ini tidak berlaku di Windows secara {i>default<i}. Sebagai gantinya, gunakanrlocationpath
untuk dukungan lintas platform.Ini mirip dengan
execpath
, tetapi menghapus konfigurasi awalan yang dijelaskan di atas. Dalam contoh di atas, ini berartiempty.source
danapp
menggunakan ruang kerja relatif murni jalur:testapp/empty.source
dantestapp/app
.rootpath
file di repositori eksternalrepo
akan diawali dengan../repo/
, diikuti dengan jalur repositori-relatif.Kode ini memiliki "satu output saja" yang sama persyaratannya sebagai
execpath
. -
rlocationpath
: Jalur yang dapat diteruskan biner build ke fungsiRlocation
library runfiles untuk menemukan dependensi di runtime, baik di direktori runfiles (jika tersedia) atau menggunakan manifes {i>runfiles<i}.Ini mirip dengan
rootpath
karena tidak berisi awalan konfigurasi, tetapi berbeda karena selalu dimulai dengan dari nama repositori. Dalam contoh di atas, ini berartiempty.source
danapp
menghasilkan hal berikut jalur:myproject/testapp/empty.source
danmyproject/testapp/app
.rlocationpath
file di repositori eksternalrepo
akan diawali denganrepo/
, diikuti dengan jalur repositori-relatif.Meneruskan jalur ini ke biner dan menyelesaikannya ke jalur sistem file menggunakan {i>library<i} {i>runfiles <i}adalah pendekatan yang lebih disukai untuk menemukan dependensi di waktu beroperasi. Dibandingkan dengan
rootpath
, terdapat keunggulan berfungsi di semua platform dan bahkan jika direktori {i>runfiles <i}tidak yang tersedia.Kode ini memiliki "satu output saja" yang sama persyaratannya sebagai
execpath
. -
location
: Sinonim untukexecpath
ataurootpath
, bergantung pada atribut yang diperluas. Ini adalah perilaku pra-Starlark lama dan tidak direkomendasikan kecuali Anda benar-benar tahu apa yang dilakukannya untuk aturan tertentu. Lihat #2475 untuk mengetahui detailnya.
execpaths
, rootpaths
, rlocationpaths
,
dan locations
adalah variasi jamak dari execpath
,
rootpath
, rlocationpaths
, danlocation
,
secara berurutan. Mereka mendukung label untuk menghasilkan
banyak {i>output<i}, dalam hal ini
setiap {i>output<i} tercantum dan
dipisahkan oleh spasi. Aturan tanpa output dan formatnya salah
label akan menghasilkan error build.
Semua label yang direferensikan harus muncul di srcs
target yang memakai,
file output, atau deps
. Jika tidak, build akan gagal. Target C++ dapat
juga merujuk label di data
.
Label tidak harus dalam bentuk kanonis: foo
, :foo
dan //somepkg:foo
baik-baik saja.
Variabel kustom
"Merek" Kustom variabel dapat direferensikan oleh atribut apa pun yang ditandai sebagai "Bergantung pada 'Buat variabel' substitusi", tetapi hanya pada target yang bergantung pada target lain yang menentukan variabel tersebut.
Sebagai praktik terbaik, semua variabel harus disesuaikan kecuali jika ada untuk memasukkannya ke dalam inti Bazel. Dengan demikian, Bazel tidak perlu melakukan dependensi yang berpotensi mahal untuk memasok variabel yang memakai {i>taret<i} mungkin tidak dipedulikan.
Variabel toolchain C++
Berikut ini yang ditetapkan dalam aturan toolchain C++ dan tersedia untuk aturan apa pun
yang menyetel toolchains =
["@bazel_tools//tools/cpp:current_cc_toolchain"]
Beberapa aturan, seperti java_binary
, secara implisit
menyertakan toolchain C++ dalam definisi aturannya. Mereka mewarisi variabel ini
secara otomatis.
Aturan C++ bawaan jauh lebih canggih daripada "Kita". Untuk mendukung mode kompilasi beragam seperti *SAN, ThinLTO, dengan/tanpa modul, serta biner yang dioptimalkan dengan cermat pada waktu yang sama dengan pengujian cepat di banyak platform, aturan bawaan berguna untuk memastikan input, output, dan tanda command line yang benar telah ditetapkan pada setiap kemungkinan beberapa tindakan yang dihasilkan secara internal.
Variabel-variabel ini merupakan mekanisme fallback untuk digunakan oleh ahli bahasa dalam yang jarang terjadi. Jika Anda tergoda untuk menggunakannya, harap hubungi developer Bazel terlebih dahulu.
ABI
: Versi ABI C++.-
AR
: "ar" dari {i>crosstool<i}. -
C_COMPILER
: ID compiler C/C++, mis.llvm
. -
CC
: Perintah compiler C dan C++.Kami sangat menyarankan agar selalu menggunakan
CC_FLAGS
di kombinasi denganCC
. Jika tidak melakukannya, risikonya Anda tanggung sendiri. CC_FLAGS
: Kumpulan tanda minimal untuk C/C++ compiler agar dapat digunakan oleh genrules. Secara khusus, file ini berisi penanda untuk pilih arsitektur yang benar jikaCC
mendukung beberapa terkait arsitektur.-
NM
: "nm" dari {i>crosstool<i}. -
OBJCOPY
: Perintah objcopy dari suite yang sama dengan C/C++ compiler. -
STRIP
: Perintah strip dari suite yang sama dengan C/C++ compiler.
Variabel toolchain Java
Berikut ini yang ditetapkan dalam aturan toolchain Java dan tersedia untuk aturan apa pun
yang menetapkan toolchains =
["@bazel_tools//tools/jdk:current_java_runtime"]
(atau
"@bazel_tools//tools/jdk:current_host_java_runtime"
untuk toolchain host yang setara).
Sebagian besar alat di JDK tidak boleh digunakan secara langsung. Java bawaan menggunakan pendekatan yang jauh lebih canggih untuk kompilasi dan pengemasan Java daripada yang dapat ditunjukkan oleh alat upstream, seperti antarmuka Jars, antarmuka header Jar, serta implementasi penggabungan dan pengemasan Jar yang sangat dioptimalkan.
Variabel-variabel ini merupakan mekanisme fallback untuk digunakan oleh ahli bahasa dalam yang jarang terjadi. Jika Anda tergoda untuk menggunakannya, harap hubungi developer Bazel terlebih dahulu.
-
JAVA
: "java" perintah Java Virtual komputer). Hindari hal ini, dan gunakan aturanjava_binary
sebagai gantinya jika memungkinkan. Mungkin jalur relatif. Jika Anda harus mengubah direktori sebelum memanggiljava
, Anda harus menangkap pada direktori kerja sebelum mengubahnya. JAVABASE
: Direktori dasar yang berisi direktori Utilitas Java. Mungkin jalur relatif. Properti tersebut akan memiliki "tempat sampah" subdirektori.
Variabel yang ditentukan Starlark
Penulis aturan dan toolchain dapat menentukan
variabel yang sepenuhnya kustom dengan menampilkan
TemplateVariableInfo
penyedia layanan. Aturan apa pun yang bergantung pada
Atribut toolchains
kemudian dapat membaca nilainya: