Правила
псевдоним
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
Правило alias создает другое имя, по которому можно обратиться к правилу.
Использование псевдонимов работает только для «обычных» целей. В частности, package_group и test_suite использовать псевдонимы нельзя.
Использование псевдонимов может быть полезно в больших репозиториях, где переименование цели потребовало бы внесения изменений во множество файлов. Также можно использовать правило псевдонима для хранения вызова функции select, если нужно повторно использовать эту логику для нескольких целей.
Правило псевдонима имеет собственное объявление видимости. Во всех остальных отношениях оно ведет себя как правило, к которому оно ссылается (например, 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 флаг),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.
