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