Правила
псевдоним
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(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),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(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",
],
)
