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