Правила
псевдоним
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
Правило alias создает другое имя, под которым может быть указано правило.
Использование псевдонима работает только для «обычных» целей. В частности, package_group и test_suite использовать псевдоним нельзя.
Правило псевдонима имеет свою собственную декларацию видимости. Во всех других отношениях оно ведет себя как правило, к которому оно ссылается (например, testonly в псевдониме игнорируется; вместо этого используется testonly-характер ссылаемого правила) с некоторыми незначительными исключениями:
- Тесты не выполняются, если их псевдоним указан в командной строке. Чтобы определить псевдоним, который запускает ссылаемый тест, используйте правило
test_suiteс единственной целью в атрибутеtests. - При определении групп окружения псевдонимы правил
environmentне поддерживаются. Они также не поддерживаются в параметре командной строки--target_environment.
Примеры
filegroup(
name = "data",
srcs = ["data.txt"],
)
alias(
name = "other",
actual = ":data",
)
Аргументы
| Атрибуты | |
|---|---|
name |
Уникальное имя для этой цели. |
actual |
|
config_setting
config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
Соответствует ожидаемому состоянию конфигурации (выраженному как флаги сборки или ограничения платформы) для запуска настраиваемых атрибутов. Смотрите select для того, как использовать это правило, и Настраиваемые атрибуты для обзора данной функции.
Примеры
Следующее соответствует любой сборке, которая устанавливает --compilation_mode=opt или -c opt (явно в командной строке или неявно из файлов .bazelrc):
config_setting(
name = "simple",
values = {"compilation_mode": "opt"}
)
Следующее соответствует любой сборке, которая нацелена на ARM и применяет пользовательское определение FOO=bar (например, bazel build --cpu=arm --define FOO=bar ...):
config_setting(
name = "two_conditions",
values = {
"cpu": "arm",
"define": "FOO=bar"
}
)
Следующее соответствует любой сборке, которая устанавливает пользовательский флаг --//custom_flags:foo=1 (явно в командной строке или неявно из файлов .bazelrc):
config_setting(
name = "my_custom_flag_is_set",
flag_values = { "//custom_flags:foo": "1" },
)
Следующее соответствует любой сборке, которая нацелена на платформу с архитектурой x86_64 и glibc версии 2.25, предполагая существование constraint_value с меткой //example:glibc_2_25. Обратите внимание, что платформа по-прежнему соответствует, если она определяет дополнительные значения ограничений помимо этих двух.
config_setting(
name = "64bit_glibc_2_25",
constraint_values = [
"@platforms//cpu:x86_64",
"//example:glibc_2_25",
]
)
Во всех этих случаях конфигурация может измениться в ходе сборки, например, если цель должна быть скомпилирована для другой платформы, чем ее зависимость. Это означает, что даже если config_setting не соответствует флагам командной строки верхнего уровня, оно может все еще соответствовать некоторым целям сборки. Примечания
- См. select, что происходит, когда несколько
config_settingсоответствуют текущему состоянию конфигурации. - Для флагов, которые поддерживают сокращенные формы (например,
--compilation_modeпо сравнению с-c), определенияvaluesдолжны использовать полную форму. Они автоматически соответствуют вызовам с использованием любой формы. - Если флаг принимает несколько значений (например,
--copt=-Da --copt=-Dbили список типа Starlark flag),values = { "flag": "a" }соответствует, если"a"присутствует где-либо в фактическом списке.values = { "myflag": "a,b" }работает так же: это соответствует--myflag=a --myflag=b,--myflag=a --myflag=b --myflag=c,--myflag=a,b, и--myflag=c,b,a. Точные семантики зависят от флагов. Например,--coptне поддерживает несколько значений в одном экземпляре:--copt=a,bдает["a,b"], а--copt=a --copt=bдает["a", "b"](поэтомуvalues = { "copt": "a,b" }соответствует первому, но не второму). Но--ios_multi_cpus(для правил Apple) поддерживает:-ios_multi_cpus=a,bиios_multi_cpus=a --ios_multi_cpus=bдают["a", "b"]. Тщательно проверьте определения флагов и условия, чтобы проверить точные ожидания. - Если вам нужны условия, которые не моделируются встроенными флагами сборки, используйте определяемые Starlark флагами. Вы также можете использовать
--define, но это предлагает более слабую поддержку и не рекомендуется. См. здесь для более подробного обсуждения. - Избегайте повторения одинаковых
config_settingопределений в разных пакетах. Вместо этого ссылайтесь на общееconfig_settingопределение в каноническом пакете. -
values,define_values, иconstraint_valuesмогут быть использованы в любом сочетании в том жеconfig_setting, но хотя бы одно должно быть установлено для любого данногоconfig_setting.
Аргументы
| Атрибуты | |
|---|---|
name |
Уникальное имя для этой цели. |
constraint_values |
constraint_values что платформа-цель должна указать, чтобы соответствовать этому config_setting. (Платформа выполнения здесь не рассматривается.) Любые дополнительные значения ограничений, которые есть у платформы, игнорируются. См. Настраиваемые атрибуты сборки для получения дополнительной информации. В случае, когда два |
define_values |
values, но конкретно для флага --define.
Это означает:
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",
})
правильно соответствует
|
flag_values |
values, но для пользовательских флагов сборки. Это отдельный атрибут, потому что пользовательские флаги ссылаются на метки, а встроенные флаги — на произвольные строки. |
values |
Это правило наследует конфигурацию настроенной цели, которая ссылается на него в инструкции Для удобства, значения конфигурации указываются как флаги сборки (без предшествующего Если флаг явно не установлен в командной строке, используется его значение по умолчанию. Если ключ появляется несколько раз в словаре, используется только последний экземпляр. Если ключ ссылается на флаг, который может быть установлен несколько раз в командной строке (например, |
filegroup
filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
Используйте filegroup для удобного именования коллекции целей. Затем они могут быть использованы в других правилах.
Рекомендуется использовать filegroup вместо непосредственной ссылки на каталоги. Последний ненадёжен, так как система сборки не обладает полным знанием всех файлов в каталоге, поэтому она может не перестроить их при изменении этих файлов. В сочетании с glob, filegroup может гарантировать, что все файлы явным образом известны системе сборки.
Примеры
Чтобы создать filegroup, состоящий из двух исходных файлов, сделайте
filegroup(
name = "mygroup",
srcs = [
"a_file.txt",
"some/subdirectory/another_file.txt",
],
)
Или, используйте glob для обхода каталога testdata:
filegroup(
name = "exported_testdata",
srcs = glob([
"testdata/*.dat",
"testdata/logs/**/*.log",
]),
)
Чтобы использовать эти определения, сошлитесь на filegroup с меткой из любого правила:
cc_library(
name = "my_library",
srcs = ["foo.cc"],
data = [
"//my_package:exported_testdata",
"//my_package:mygroup",
],
)
