Halaman ini membahas manfaat dan penggunaan dasar konfigurasi Starlark, API Bazel untuk menyesuaikan cara build project Anda. Panduan ini mencakup cara menentukan setelan build dan memberikan contoh.
Hal ini memungkinkan untuk:
- menentukan flag kustom untuk project Anda, yang meniadakan kebutuhan akan
--define
- menulis
transitions untuk mengonfigurasi dependensi dalam
konfigurasi yang berbeda dengan induknya
(seperti
--compilation_mode=opt
atau--cpu=arm
) - Memasukkan default yang lebih baik ke dalam aturan (seperti otomatis mem-build
//my:android_app
dengan SDK yang ditentukan)
dan masih banyak lagi, seluruhnya dari file .bzl (tidak diperlukan rilis Bazel). Lihat
repositori bazelbuild/examples
untuk
contoh.
Setelan build yang ditentukan pengguna
Setelan build adalah bagian tunggal dari informasi konfigurasi. Anggaplah konfigurasi sebagai peta kunci/nilai. Menetapkan --cpu=ppc
dan --copt="-DFoo"
akan menghasilkan konfigurasi yang terlihat seperti
{cpu: ppc, copt: "-DFoo"}
. Setiap entri adalah setelan build.
Flag tradisional seperti cpu
dan copt
adalah setelan native —
kuncinya ditentukan dan nilainya ditetapkan di dalam kode java bazel native.
Pengguna Bazel hanya dapat membaca dan menulisnya melalui command line
dan API lain yang dikelola secara native. Mengubah flag native, dan API
yang mengeksposnya, memerlukan rilis bazel. Setelan build
yang ditentukan pengguna ditentukan dalam file .bzl
(sehingga, tidak memerlukan rilis bazel untuk
mendaftarkan perubahan). Parameter ini juga dapat ditetapkan melalui command line (jika ditetapkan sebagai flags
, lihat selengkapnya di bawah), tetapi juga dapat ditetapkan melalui transisi yang ditentukan pengguna.
Menentukan setelan build
Parameter build_setting
rule()
Setelan build adalah aturan seperti aturan lainnya dan dibedakan menggunakan atribut build_setting
dari fungsi rule()
Starlark.
# example/buildsettings/build_settings.bzl
string_flag = rule(
implementation = _impl,
build_setting = config.string(flag = True)
)
Atribut build_setting
menggunakan fungsi yang menentukan jenis
setelan build. Jenis ini terbatas pada sekumpulan jenis Starlark dasar seperti
bool
dan string
. Lihat dokumentasi modul config
untuk mengetahui detailnya. Ketik yang lebih rumit dapat dilakukan
dalam fungsi implementasi aturan. Selengkapnya di bawah ini.
Fungsi modul config
menggunakan parameter boolean opsional, flag
,
yang ditetapkan ke false secara default. Jika flag
disetel ke benar (true), setelan build
dapat ditetapkan pada command line oleh pengguna serta secara internal oleh penulis aturan
melalui nilai default dan transisi.
Tidak semua setelan harus dapat disetel oleh pengguna. Misalnya, jika Anda sebagai penulis aturan memiliki beberapa mode debug yang ingin diaktifkan di dalam aturan pengujian, Anda tentu tidak ingin memberi pengguna kemampuan untuk mengaktifkan fitur tersebut tanpa alasan di dalam aturan non-pengujian lainnya.
Menggunakan ctx.build_setting_value
Seperti semua aturan, aturan setelan build memiliki fungsi implementasi.
Nilai dasar jenis Starlark dari setelan build dapat diakses melalui
metode ctx.build_setting_value
. Metode ini hanya tersedia untuk
objek ctx
dalam aturan setelan build. Metode
implementasi ini dapat langsung meneruskan nilai setelan build atau melakukan pekerjaan tambahan pada
nilai tersebut, seperti pemeriksaan jenis atau pembuatan struct yang lebih kompleks. Berikut cara
mengimplementasikan setelan build berjenis enum
:
# example/buildsettings/build_settings.bzl
TemperatureProvider = provider(fields = ['type'])
temperatures = ["HOT", "LUKEWARM", "ICED"]
def _impl(ctx):
raw_temperature = ctx.build_setting_value
if raw_temperature not in temperatures:
fail(str(ctx.label) + " build setting allowed to take values {"
+ ", ".join(temperatures) + "} but was set to unallowed value "
+ raw_temperature)
return TemperatureProvider(type = raw_temperature)
temperature = rule(
implementation = _impl,
build_setting = config.string(flag = True)
)
Menentukan flag string multi-set
Setelan string memiliki parameter allow_multiple
tambahan yang memungkinkan
flag ditetapkan beberapa kali pada command line atau di bazelrc. Nilai defaultnya
masih ditetapkan dengan atribut berjenis string:
# example/buildsettings/build_settings.bzl
allow_multiple_flag = rule(
implementation = _impl,
build_setting = config.string(flag = True, allow_multiple = True)
)
# example/buildsettings/BUILD
load("//example/buildsettings:build_settings.bzl", "allow_multiple_flag")
allow_multiple_flag(
name = "roasts",
build_setting_default = "medium"
)
Setiap setelan flag diperlakukan sebagai satu nilai:
$ bazel build //my/target --//example:roasts=blonde \
--//example:roasts=medium,dark
Hal di atas diuraikan menjadi {"//example:roasts": ["blonde", "medium,dark"]}
dan
ctx.build_setting_value
akan menampilkan daftar ["blonde", "medium,dark"]
.
Membuat instance setelan build
Aturan yang ditentukan dengan parameter build_setting
memiliki atribut
build_setting_default
wajib yang implisit. Atribut ini menggunakan jenis yang sama seperti
yang dideklarasikan oleh parameter build_setting
.
# example/buildsettings/build_settings.bzl
FlavorProvider = provider(fields = ['type'])
def _impl(ctx):
return FlavorProvider(type = ctx.build_setting_value)
flavor = rule(
implementation = _impl,
build_setting = config.string(flag = True)
)
# example/buildsettings/BUILD
load("//example/buildsettings:build_settings.bzl", "flavor")
flavor(
name = "favorite_flavor",
build_setting_default = "APPLE"
)
Setelan standar
Library Skylib menyertakan kumpulan setelan standar yang dapat Anda buat instance-nya tanpa harus menulis Starlark kustom.
Misalnya, untuk menentukan setelan yang menerima serangkaian nilai string terbatas:
# example/BUILD
load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
string_flag(
name = "myflag",
values = ["a", "b", "c"],
build_setting_default = "a",
)
Untuk mengetahui daftar lengkapnya, lihat Aturan setelan build umum.
Menggunakan setelan build
Bergantung pada setelan build
Jika ingin membaca sebagian informasi konfigurasi, target dapat langsung bergantung pada setelan build melalui dependensi atribut reguler.
# example/rules.bzl
load("//example/buildsettings:build_settings.bzl", "FlavorProvider")
def _rule_impl(ctx):
if ctx.attr.flavor[FlavorProvider].type == "ORANGE":
...
drink_rule = rule(
implementation = _rule_impl,
attrs = {
"flavor": attr.label()
}
)
# example/BUILD
load("//example:rules.bzl", "drink_rule")
load("//example/buildsettings:build_settings.bzl", "flavor")
flavor(
name = "favorite_flavor",
build_setting_default = "APPLE"
)
drink_rule(
name = "my_drink",
flavor = ":favorite_flavor",
)
Berbagai bahasa mungkin ingin membuat kumpulan kanonis setelan build yang diandalkan oleh semua aturan untuk bahasa tersebut. Meskipun konsep native fragments
tidak lagi ada
sebagai objek yang di-hardcode di dunia konfigurasi Starlark, salah satu cara
untuk menerjemahkan konsep ini adalah dengan menggunakan serangkaian atribut implisit umum. Contoh:
# kotlin/rules.bzl
_KOTLIN_CONFIG = {
"_compiler": attr.label(default = "//kotlin/config:compiler-flag"),
"_mode": attr.label(default = "//kotlin/config:mode-flag"),
...
}
...
kotlin_library = rule(
implementation = _rule_impl,
attrs = dicts.add({
"library-attr": attr.string()
}, _KOTLIN_CONFIG)
)
kotlin_binary = rule(
implementation = _binary_impl,
attrs = dicts.add({
"binary-attr": attr.label()
}, _KOTLIN_CONFIG)
Menggunakan setelan build pada command line
Serupa dengan sebagian besar tanda native, Anda dapat menggunakan command line untuk menetapkan setelan build
yang ditandai sebagai tanda. Nama setelan
build adalah jalur target lengkapnya yang menggunakan sintaksis name=value
:
$ bazel build //my/target --//example:string_flag=some-value # allowed
$ bazel build //my/target --//example:string_flag some-value # not allowed
Sintaksis boolean khusus didukung:
$ bazel build //my/target --//example:boolean_flag
$ bazel build //my/target --no//example:boolean_flag
Menggunakan alias setelan build
Anda dapat menetapkan alias untuk jalur target setelan build agar lebih mudah dibaca di command line. Fungsi alias mirip dengan tanda native dan juga menggunakan sintaksis opsi tanda hubung ganda.
Tetapkan alias dengan menambahkan --flag_alias=ALIAS_NAME=TARGET_PATH
ke .bazelrc
Anda . Misalnya, untuk menetapkan alias ke coffee
:
# .bazelrc
build --flag_alias=coffee=//experimental/user/starlark_configurations/basic_build_setting:coffee-temp
Praktik Terbaik: Menetapkan alias beberapa kali akan menghasilkan alias terbaru lebih diutamakan. Gunakan nama alias unik untuk menghindari hasil penguraian yang tidak diinginkan.
Untuk menggunakan alias, ketik alias sebagai pengganti jalur target setelan build.
Dengan contoh coffee
di atas yang ditetapkan dalam .bazelrc
pengguna:
$ bazel build //my/target --coffee=ICED
bukan
$ bazel build //my/target --//experimental/user/starlark_configurations/basic_build_setting:coffee-temp=ICED
Praktik Terbaik: Meskipun menetapkan alias pada command line dapat dilakukan, membiarkannya
dalam .bazelrc
akan mengurangi kekacauan command line.
Setelan build berjenis label
Tidak seperti setelan build lainnya, setelan berjenis label tidak dapat ditentukan menggunakan
parameter aturan build_setting
. Sebagai gantinya, bazel memiliki dua aturan bawaan:
label_flag
dan label_setting
. Aturan ini meneruskan penyedia
target sebenarnya yang menjadi tempat setelan build. label_flag
dan label_setting
dapat dibaca/ditulis oleh transisi dan label_flag
dapat disetel oleh pengguna seperti aturan build_setting
lainnya. Satu-satunya perbedaan mereka adalah mereka
tidak dapat didefinisikan secara khusus.
Setelan berjenis label pada akhirnya akan menggantikan fungsi default terikat akhir. Atribut default batas akhir adalah atribut berjenis Label yang nilai akhirnya dapat terpengaruh oleh konfigurasi. Di Starlark, ini akan menggantikan
configuration_field
API.
# example/rules.bzl
MyProvider = provider(fields = ["my_field"])
def _dep_impl(ctx):
return MyProvider(my_field = "yeehaw")
dep_rule = rule(
implementation = _dep_impl
)
def _parent_impl(ctx):
if ctx.attr.my_field_provider[MyProvider].my_field == "cowabunga":
...
parent_rule = rule(
implementation = _parent_impl,
attrs = { "my_field_provider": attr.label() }
)
# example/BUILD
load("//example:rules.bzl", "dep_rule", "parent_rule")
dep_rule(name = "dep")
parent_rule(name = "parent", my_field_provider = ":my_field_provider")
label_flag(
name = "my_field_provider",
build_setting_default = ":dep"
)
Pengaturan build dan select()
Pengguna dapat mengonfigurasi atribut pada setelan build menggunakan
select()
. Target setelan build dapat diteruskan ke atribut flag_values
dari
config_setting
. Nilai yang akan dicocokkan dengan konfigurasi diteruskan sebagai
String
, lalu diuraikan ke jenis setelan build untuk pencocokan.
config_setting(
name = "my_config",
flag_values = {
"//example:favorite_flavor": "MANGO"
}
)
Transisi yang ditentukan pengguna
Transisi konfigurasi memetakan transformasi dari satu target yang dikonfigurasi ke target lainnya dalam grafik build.
Aturan yang menetapkannya harus menyertakan atribut khusus:
"_allowlist_function_transition": attr.label(
default = "@bazel_tools//tools/allowlists/function_transition_allowlist"
)
Dengan menambahkan transisi, Anda dapat dengan mudah memperluas ukuran grafik build. Tindakan ini menetapkan daftar yang diizinkan pada paket tempat Anda dapat membuat target aturan ini. Nilai default dalam blok kode di atas mengizinkan semua hal. Namun, jika ingin membatasi siapa saja yang menggunakan aturan, Anda dapat menetapkan atribut tersebut agar mengarah ke daftar yang diizinkan kustom sendiri. Hubungi bazel-discuss@googlegroups.com jika Anda memerlukan saran atau bantuan untuk memahami pengaruh transisi terhadap performa build Anda.
Menentukan
Transisi mendefinisikan perubahan konfigurasi antaraturan. Misalnya, permintaan seperti "kompilasi dependensi saya untuk CPU yang berbeda dari induknya" ditangani oleh transisi.
Secara formal, transisi adalah fungsi dari konfigurasi input ke satu atau beberapa konfigurasi output. Sebagian besar transisi bersifat 1:1 seperti "mengganti konfigurasi
input dengan --cpu=ppc
". Transisi 1:2+ juga dapat terjadi tetapi memiliki
batasan khusus.
Di Starlark, transisi didefinisikan seperti aturan, dengan fungsi transition()
dan fungsi implementasi yang menentukan.
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return {"//example:favorite_flavor" : "MINT"}
hot_chocolate_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//example:favorite_flavor"]
)
Fungsi transition()
menggunakan fungsi implementasi, sekumpulan
setelan build yang akan dibaca(inputs
), dan kumpulan setelan build untuk ditulis
(outputs
). Fungsi implementasi memiliki dua parameter, settings
dan
attr
. settings
adalah kamus {String
:Object
} dari semua setelan yang dideklarasikan
dalam parameter inputs
untuk transition()
.
attr
adalah kamus atribut dan nilai aturan tempat
transisi dilampirkan. Saat dilampirkan sebagai transisi edge keluar, nilai atribut ini semuanya dikonfigurasi dengan resolusi pasca-select(). Jika dilampirkan sebagai
transisi edge yang masuk, attr
tidak
menyertakan atribut apa pun yang menggunakan pemilih untuk me-resolve nilainya. Jika
transisi tepi yang masuk pada --foo
membaca atribut bar
, lalu juga
memilih --foo
untuk menyetel atribut bar
, akan ada kemungkinan bagi
transisi tepi yang masuk akan membaca nilai bar
yang salah dalam transisi.
Fungsi implementasi harus menampilkan kamus (atau daftar
kamus, jika terjadi
transisi dengan beberapa konfigurasi output)
dari nilai setelan build baru yang akan diterapkan. Keyset kamus yang ditampilkan harus
berisi persis kumpulan setelan build yang diteruskan ke parameter outputs
dari fungsi transisi. Hal ini berlaku meskipun setelan build
tidak benar-benar berubah selama transisi - nilai aslinya harus
diteruskan secara eksplisit dalam kamus yang ditampilkan.
Menentukan transisi 1:2+
Transisi tepi keluar dapat memetakan satu konfigurasi input ke dua atau beberapa konfigurasi output. Hal ini berguna untuk menentukan aturan yang memaketkan kode multi-arsitektur.
Transisi 1:2+ ditentukan dengan menampilkan daftar kamus dalam fungsi implementasi transisi.
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return [
{"//example:favorite_flavor" : "LATTE"},
{"//example:favorite_flavor" : "MOCHA"},
]
coffee_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//example:favorite_flavor"]
)
Mereka juga dapat menetapkan kunci kustom yang dapat digunakan oleh fungsi implementasi aturan untuk membaca dependensi individual:
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return {
"Apple deps": {"//command_line_option:cpu": "ppc"},
"Linux deps": {"//command_line_option:cpu": "x86"},
}
multi_arch_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//command_line_option:cpu"]
)
Melampirkan transisi
Transisi dapat dipasang di dua tempat: tepi yang masuk dan tepi keluar. Secara efektif, ini berarti aturan dapat mentransisikan konfigurasinya sendiri (transisi edge masuk) dan mentransisikan konfigurasi dependensinya (transisi edge keluar).
CATATAN: Saat ini tidak ada cara untuk melampirkan transisi Starlark ke aturan native. Jika Anda perlu melakukannya, hubungi bazel-discuss@googlegroups.com untuk mendapatkan bantuan dalam mencari solusi.
Transisi tepi yang masuk
Transisi tepi yang masuk diaktifkan dengan melampirkan objek transition
(dibuat oleh transition()
) ke parameter cfg
rule()
:
# example/rules.bzl
load("example/transitions:transitions.bzl", "hot_chocolate_transition")
drink_rule = rule(
implementation = _impl,
cfg = hot_chocolate_transition,
...
Transisi tepi yang masuk harus berupa transisi 1:1.
Transisi tepi keluar
Transisi tepi keluar diaktifkan dengan melampirkan objek transition
(dibuat oleh transition()
) ke parameter cfg
atribut:
# example/rules.bzl
load("example/transitions:transitions.bzl", "coffee_transition")
drink_rule = rule(
implementation = _impl,
attrs = { "dep": attr.label(cfg = coffee_transition)}
...
Transisi tepi keluar dapat berupa 1:1 atau 1:2+.
Lihat Mengakses atribut dengan transisi untuk mengetahui cara membaca kunci ini.
Transisi pada opsi native
Transisi Starlark juga dapat mendeklarasikan pembacaan dan penulisan pada opsi konfigurasi build native melalui awalan khusus ke nama opsi.
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return {"//command_line_option:cpu": "k8"}
cpu_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//command_line_option:cpu"]
Opsi native yang tidak didukung
Bazel tidak mendukung transisi pada --define
dengan
"//command_line_option:define"
. Sebagai gantinya, gunakan setelan build kustom. Secara umum, penggunaan baru
--define
tidak disarankan untuk mendukung setelan build.
Bazel tidak mendukung transisi pada --config
. Ini karena --config
adalah
flag "ekspansi" yang diperluas ke flag lain.
Yang terpenting, --config
dapat menyertakan flag yang tidak memengaruhi konfigurasi build,
seperti
--spawn_strategy
. Bazel secara desainnya tidak dapat mengikat flag tersebut ke masing-masing target. Artinya,
tidak ada cara yang koheren untuk menerapkannya dalam transisi.
Sebagai solusinya, Anda dapat secara eksplisit menampilkan item tanda yang merupakan bagian dari konfigurasi dalam transisi Anda. Hal ini memerlukan mempertahankan perluasan
--config
di dua tempat, yang merupakan noda UI yang diketahui.
Transisi aktif memungkinkan beberapa setelan build
Saat menetapkan setelan build yang mengizinkan beberapa nilai, nilai setelan harus ditetapkan dengan daftar.
# example/buildsettings/build_settings.bzl
string_flag = rule(
implementation = _impl,
build_setting = config.string(flag = True, allow_multiple = True)
)
# example/BUILD
load("//example/buildsettings:build_settings.bzl", "string_flag")
string_flag(name = "roasts", build_setting_default = "medium")
# example/transitions/rules.bzl
def _transition_impl(settings, attr):
# Using a value of just "dark" here will throw an error
return {"//example:roasts" : ["dark"]},
coffee_transition = transition(
implementation = _transition_impl,
inputs = [],
outputs = ["//example:roasts"]
)
Transisi tanpa pengoperasian
Jika transisi menampilkan {}
, []
, atau None
, ini adalah cara pintas untuk mempertahankan semua
setelan pada nilai aslinya. Ini akan lebih mudah daripada menetapkan setiap output secara eksplisit ke dirinya sendiri.
# example/transitions/transitions.bzl
def _impl(settings, attr):
_ignore = (attr)
if settings["//example:already_chosen"] is True:
return {}
return {
"//example:favorite_flavor": "dark chocolate",
"//example:include_marshmallows": "yes",
"//example:desired_temperature": "38C",
}
hot_chocolate_transition = transition(
implementation = _impl,
inputs = ["//example:already_chosen"],
outputs = [
"//example:favorite_flavor",
"//example:include_marshmallows",
"//example:desired_temperature",
]
)
Mengakses atribut dengan transisi
Saat melampirkan transisi ke edge keluar
(terlepas dari apakah transisi tersebut merupakan transisi 1:1 atau 1:2+), ctx.attr
terpaksa menjadi daftar
jika belum. Urutan elemen dalam daftar ini tidak ditentukan.
# example/transitions/rules.bzl
def _transition_impl(settings, attr):
return {"//example:favorite_flavor" : "LATTE"},
coffee_transition = transition(
implementation = _transition_impl,
inputs = [],
outputs = ["//example:favorite_flavor"]
)
def _rule_impl(ctx):
# Note: List access even though "dep" is not declared as list
transitioned_dep = ctx.attr.dep[0]
# Note: Access doesn't change, other_deps was already a list
for other dep in ctx.attr.other_deps:
# ...
coffee_rule = rule(
implementation = _rule_impl,
attrs = {
"dep": attr.label(cfg = coffee_transition)
"other_deps": attr.label_list(cfg = coffee_transition)
})
Jika transisinya adalah 1:2+
dan menetapkan kunci kustom, ctx.split_attr
dapat digunakan untuk membaca dependensi individual untuk setiap kunci:
# example/transitions/rules.bzl
def _impl(settings, attr):
_ignore = (settings, attr)
return {
"Apple deps": {"//command_line_option:cpu": "ppc"},
"Linux deps": {"//command_line_option:cpu": "x86"},
}
multi_arch_transition = transition(
implementation = _impl,
inputs = [],
outputs = ["//command_line_option:cpu"]
)
def _rule_impl(ctx):
apple_dep = ctx.split_attr.dep["Apple deps"]
linux_dep = ctx.split_attr.dep["Linux deps"]
# ctx.attr has a list of all deps for all keys. Order is not guaranteed.
all_deps = ctx.attr.dep
multi_arch_rule = rule(
implementation = _rule_impl,
attrs = {
"dep": attr.label(cfg = multi_arch_transition)
})
Lihat contoh lengkap di sini.
Integrasi dengan platform dan toolchain
Banyak flag native saat ini, seperti --cpu
dan --crosstool_top
terkait dengan resolusi toolchain. Di masa mendatang, transisi eksplisit pada jenis flag ini kemungkinan akan diganti dengan transisi pada platform target.
Pertimbangan memori dan performa
Menambahkan transisi, dan karenanya konfigurasi baru, ke build Anda memiliki konsekuensi: grafik build yang lebih besar, grafik build yang kurang mudah dipahami, dan build yang lebih lambat. Sebaiknya pertimbangkan biaya ini saat mempertimbangkan penggunaan transisi dalam aturan build Anda. Di bawah ini adalah contoh bagaimana transisi dapat menghasilkan pertumbuhan eksponensial grafik build Anda.
Build berperilaku buruk: studi kasus
Gambar 1. Grafik skalabilitas yang menampilkan target tingkat atas dan dependensinya.
Grafik ini menunjukkan target tingkat teratas, //pkg:app, yang bergantung pada dua target, yakni //pkg:1_0 dan //pkg:1_1. Kedua target ini bergantung pada dua target, //pkg:2_0 dan //pkg:2_1. Kedua target ini bergantung pada dua target, //pkg:3_0 dan //pkg:3_1. Ini berlanjut hingga //pkg:n_0 dan //pkg:n_1, yang keduanya bergantung pada satu target, //pkg:dep.
Membuat //pkg:app
membutuhkan \(2n+2\) target:
//pkg:app
//pkg:dep
//pkg:i_0
dan//pkg:i_1
untuk \(i\) dalam \([1..n]\)
Bayangkan Anda implement) flag
--//foo:owner=<STRING>
dan //pkg:i_b
berlaku
depConfig = myConfig + depConfig.owner="$(myConfig.owner)$(b)"
Dengan kata lain, //pkg:i_b
menambahkan b
ke nilai lama --owner
untuk semua
dependensinya.
Tindakan ini menghasilkan target yang dikonfigurasi berikut:
//pkg:app //foo:owner=""
//pkg:1_0 //foo:owner=""
//pkg:1_1 //foo:owner=""
//pkg:2_0 (via //pkg:1_0) //foo:owner="0"
//pkg:2_0 (via //pkg:1_1) //foo:owner="1"
//pkg:2_1 (via //pkg:1_0) //foo:owner="0"
//pkg:2_1 (via //pkg:1_1) //foo:owner="1"
//pkg:3_0 (via //pkg:1_0 → //pkg:2_0) //foo:owner="00"
//pkg:3_0 (via //pkg:1_0 → //pkg:2_1) //foo:owner="01"
//pkg:3_0 (via //pkg:1_1 → //pkg:2_0) //foo:owner="10"
//pkg:3_0 (via //pkg:1_1 → //pkg:2_1) //foo:owner="11"
...
//pkg:dep
menghasilkan \(2^n\) target yang dikonfigurasi: config.owner=
"\(b_0b_1...b_n\)" untuk semuanya \(b_i\) dalam \(\{0,1\}\).
Hal ini membuat grafik build menjadi lebih besar secara eksponensial daripada grafik target, dengan konsekuensi memori dan performa yang sesuai.
AKTIVITAS: Tambahkan strategi untuk pengukuran dan mitigasi masalah ini.
Bacaan lebih lanjut
Untuk detail selengkapnya tentang mengubah konfigurasi build, lihat:
- Konfigurasi Build Starlark
- Roadmap Kemampuan Konfigurasi Bazel
- Rangkaian lengkap contoh menyeluruh