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