Общие определения

В этом разделе определяются различные термины и понятия, которые являются общими для многих функций или правил сборки.

Содержание

Токенизация оболочки Bourne
Расширение меток
Типичные атрибуты, определенные большинством правил сборки
Атрибуты, общие для всех правил сборки
Атрибуты, общие для всех правил тестирования (*_test)
Атрибуты, общие для всех правил бинарных файлов (*_binary)
Настраиваемые атрибуты
Неявные целевые файлы вывода

Токенизация оболочки Bourne

Некоторые строковые атрибуты некоторых правил разбиваются на несколько слов в соответствии с правилами токенизации оболочки Bourne: нецитированные пробелы разделяют отдельные слова, а одинарные и двойные кавычки, а также обратные слэши используются для предотвращения токенизации.

Те атрибуты, которые подвергаются этой токенизации, явно указываются в их определениях в этом документе.

Атрибуты, подверженные расширению переменных «Make» и токенизации оболочки Bourne, обычно используются для передачи произвольных параметров компиляторам и другим инструментам. Примерами таких атрибутов являются cc_library.copts и java_library.javacopts. Вместе эти подстановки позволяют одной строковой переменной расширяться в список параметров, специфичных для конфигурации.

Расширение меток

Некоторые строковые атрибуты очень немногих правил подвержены расширению меток: если эти строки содержат корректную метку, как подстроку, например, //mypkg:target, и эта метка является объявленной предпосылкой текущего правила, она расширяется в путь к файлу, представленному целью //mypkg:target.

Примеры атрибутов включают genrule.cmd и cc_binary.linkopts. Подробности могут существенно отличаться в каждом случае, по таким вопросам, как: расширение относительных меток; обработка меток, расширяющихся до нескольких файлов, и т. д. Обратитесь к документации атрибутов правила для получения подробной информации.

Типичные атрибуты, определенные большинством правил сборки

В этом разделе описываются атрибуты, которые определяются многими правилами сборки, но не всеми.

Атрибут	Описание
`data`	Список меток; значение по умолчанию `[]` Файлы, необходимые этому правилу во время выполнения. Может содержать метки файлов или правил. В целом позволяет использовать любые целевые объекты. Файлы вывода и runfiles целевых объектов в атрибуте `data` должны отображаться в области `*.runfiles` любого исполняемого файла, который выводится данным объектом или имеет зависимость от времени выполнения с этим объектом. Это могут быть файлы данных или двоичные файлы, используемые при выполнении `srcs` этого объекта. Подробнее о зависимости от файлов данных см. раздел зависимости данных. Новые правила должны определять атрибут `data`, если они обрабатывают входные данные, которые могут использовать другие входные данные во время выполнения. Функции реализации правил также должны заполнять runfiles объекта из выходов и runfiles любого атрибута `data`, а также из runfiles любого атрибута зависимости, который предоставляет исходный код или зависимости времени выполнения.
`deps`	Список меток; значение по умолчанию `[]` Зависимости для этой цели. В общем случае следует указывать только целевые объекты правил. (Хотя некоторые правила позволяют указывать файлы напрямую в `deps`, этого следует избегать, когда это возможно.) Правила, специфичные для языка, обычно ограничивают указанные целевые объекты теми, которые имеют определенные провайдеры. Точный смысл того, что означает зависимость одного объекта от другого с помощью `deps`, специфичен для типа правила, и документация по правилу описывает это подробнее. Для правил, обрабатывающих исходный код, `deps` обычно указывает зависимости кода, используемые кодом в `srcs`. Чаще всего зависимость `deps` используется для того, чтобы один модуль мог использовать символы, определенные в другом модуле, написанном на том же языке программирования и скомпилированном отдельно. Встречается возможность зависимостей между языками: например, целевой объект `java_library` может зависеть от кода C++ в целевом объекте `cc_library`, указав его в атрибуте `deps`. Подробнее о зависимостях см. определение зависимостей.
`licenses`	Список строк; неперенастраиваемый; значение по умолчанию `["none"]` Список строк типа лицензии, которые должны использоваться для конкретной цели. Это часть устаревшего API лицензирования, который Bazel больше не использует. Не используйте это.
`srcs`	Список меток; значение по умолчанию `[]` Файлы, обрабатываемые или включаемые этим правилом. Обычно перечисляет файлы напрямую, но может указывать целевые объекты правил (например, `filegroup` или `genrule`) для включения их выходных файлов по умолчанию. Правила, специфичные для языка, часто требуют, чтобы перечисленные файлы имели определенные расширения.

Атрибуты, общие для всех правил сборки

В этом разделе описываются атрибуты, которые неявно добавляются ко всем правилам сборки.

Атрибут	Описание
`compatible_with`	Список меток; не настраиваемый; значение по умолчанию `[]` Список сред, для которых этот целевой объект может быть скомпилирован, помимо поддерживаемых по умолчанию сред. Это часть системы ограничений Bazel, позволяющей пользователям объявлять, какие целевые объекты могут и не могут зависеть друг от друга. Например, внешние исполняемые файлы не должны зависеть от библиотек с конфиденциальным кодом компании. Подробности см. в ConstraintSemantics.
`deprecation`	Строка; не настраиваемый; значение по умолчанию `None` Объяснительное предупреждение, связанное с этим целевым объектом. Обычно используется для уведомления пользователей о том, что целевой объект устарел или заменён другой инструкцией, является закрытым для пакета или, возможно, считается вредным по какой-либо причине. Рекомендуется указать ссылку (например, веб-страницу, номер ошибки или примеры исправляющих CL), чтобы легко найти необходимые изменения, чтобы избежать сообщения. Если есть новый целевой объект, который можно использовать как полную замену, лучше просто мигрировать всех пользователей старого целевого объекта. Этот атрибут не влияет на способ сборки, но может повлиять на вывод диагностики инструмента сборки. Инструмент сборки выводит предупреждение, когда правило с атрибутом `deprecation` зависит от целевого объекта в другом пакете. Внутрипакетные зависимости исключены из этого предупреждения, поэтому, например, сборка тестов устаревшего правила не вызывает предупреждение. Если устаревший целевой объект зависит от другого устаревшего целевого объекта, сообщение о предупреждении не выдаётся. После того, как люди перестанут его использовать, целевой объект можно удалить.
`distribs`	Список строк; не настраиваемый; значение по умолчанию `[]` Список строк методов распространения, которые будут использоваться для этого целевого объекта. Это часть устаревшего API лицензирования, которым Bazel больше не пользуется. Не используйте это.
`exec_compatible_with`	Список меток; не настраиваемый; значение по умолчанию `[]` Список `constraint_values`, которые должны присутствовать в платформе выполнения для этого целевого объекта. Это дополнительно к любым ограничениям, уже установленным типом правила. Ограничения используются для ограничения списка доступных платформ выполнения. Подробнее см. описание разрешения цепочки инструментов.
`exec_properties`	Словарь строк; значение по умолчанию `{}` Словарь строк, который будет добавлен к `exec_properties` платформы, выбранной для этого целевого объекта. См. `exec_properties` правила платформы. Если ключ присутствует как в свойствах платформы, так и в свойствах уровня целевого объекта, значение будет взято из целевого объекта.
`features`	Список строк функции; значение по умолчанию `[]` Функция — это строковый тег, который можно включить или выключить для целевого объекта. Значение функции зависит от самого правила. Этот атрибут `features` комбинируется с атрибутом уровня пакета `features`. Например, если функции ["a", "b"] включены на уровне пакета, и атрибут `features` целевого объекта содержит ["-a", "c"], то функции, включенные для правила, будут "b" и "c". См. пример.
`restricted_to`	Список меток; не настраиваемый; значение по умолчанию `[]` Список сред, для которых этот целевой объект может быть скомпилирован, вместо поддерживаемых по умолчанию сред. Это часть системы ограничений Bazel. Подробности см. в `compatible_with`
`tags`	Список строк; не настраиваемый; значение по умолчанию `[]` Теги могут использоваться для любого правила. Теги для правил тестов и `test_suite` правил полезны для категоризации тестов. Теги для целевых объектов, не являющихся тестами, используются для управления выполнением в защищённом контейнере `genrule` и Starlark действий, а также для парсинга человеком и/или внешними инструментами. Bazel изменяет поведение своей кода защищённого контейнера, если находит следующие ключевые слова в атрибуте `tags` любого правила теста или `genrule` целевого объекта, или в ключах `execution_requirements` для любого Starlark действия. `no-sandbox` ключевое слово приводит к тому, что действие или тест никогда не будут выполняться в защищённом контейнере; он всё ещё может кэшироваться или выполняться удалённо — используйте `no-cache` или `no-remote`, чтобы предотвратить тот или другой вариант. `no-cache` ключевое слово приводит к тому, что действие или тест никогда не будут кэшироваться (локально или удалённо). Примечание: для целей этого тега кэш диска считается локальным кэшем, а кэши HTTP и gRPC — удалёнными. Другие кэши, такие как Skyframe или кэш постоянных действий, не затронуты. `no-remote-cache` ключевое слово приводит к тому, что действие или тест никогда не будут кэшироваться удалённо (но могут кэшироваться локально; они также могут выполняться удалённо). Примечание: для целей этого тега кэш диска считается локальным кэшем, а кэши HTTP и gRPC — удалёнными. Другие кэши, такие как Skyframe или кэш постоянных действий, не затронуты. Если используется комбинация локального кэша диска и удалённого кэша (комбинированный кэш), он рассматривается как удалённый кэш и полностью отключается, если `--incompatible_remote_results_ignore_disk` установлен, в этом случае будут использоваться локальные компоненты. `no-remote-exec` ключевое слово приводит к тому, что действие или тест никогда не будут выполняться удалённо (но могут кэшироваться удалённо). `no-remote` ключевое слово предотвращает выполнение действия или теста удалённо или кэширование удалённо. Это эквивалентно использованию `no-remote-cache` и `no-remote-exec`. `no-remote-cache-upload` ключевое слово отключает часть загрузки удалённого кэширования спавна. Оно не отключает удалённое выполнение. `local` ключевое слово предотвращает удалённое кэширование, удалённое выполнение или выполнение действия или теста в защищённом контейнере. Для genrules и тестов пометка правила атрибутом `local = True` имеет тот же эффект. `requires-network` ключевое слово позволяет доступ к внешней сети из защищённого контейнера. Этот тег имеет эффект только если включено выполнение в защищённом контейнере. `block-network` ключевое слово блокирует доступ к внешней сети из защищённого контейнера. В этом случае разрешается только общение с localhost. Этот тег имеет эффект только если включено выполнение в защищённом контейнере. `requires-fakeroot` выполняет тест или действие как пользователь и группа 0 (т. е. root-пользователь). Поддерживается только на Linux. Этот тег имеет приоритет над параметром командной строки `--sandbox_fake_username`. Теги для тестов обычно используются для аннотирования роли теста в процессе отладки и выпуска. Обычно теги наиболее полезны для C++ и Python тестов, которые не имеют возможности добавить аннотации во время выполнения. Использование тегов и элементов размера обеспечивает гибкость в формировании наборов тестов, основанных на политике ввода кода. Bazel изменяет поведение запуска тестов, если находит следующие ключевые слова в атрибуте `tags` правила теста: `exclusive` принудительно запустит тест в режиме "исключительно", гарантируя, что другие тесты не будут выполняться одновременно. Такие тесты будут выполняться последовательно после всех операций сборки и неисключительных тестов. Удалённое выполнение отключено для таких тестов, потому что Bazel не контролирует то, что выполняется на удалённой машине. `exclusive-if-local` принудительно запустит тест в режиме "исключительно", если он выполняется локально, но выполнит тест параллельно, если он выполняется удалённо. `manual` ключевое слово исключит целевой объект из расширения шаблонов целевых объектов (`...`, `:*`, `:all`, и т. д.) и правил `test_suite`, которые не явно указывают тест при вычислении набора основных целевых объектов для сборки/выполнения для команд `build`, `test` и `coverage`. Это не влияет на расширение шаблонов целевых объектов или наборов тестов в других контекстах, включая команду `query`. Обратите внимание, что `manual` не подразумевает, что целевой объект не должен быть автоматически собран/запущен системами непрерывной сборки/тестирования. Например, может быть желательно исключить целевой объект из `bazel test ...`, потому что он требует определённых флагов Bazel, но всё ещё включать его в должным образом настроенные преподготовки или непрерывные тестовые прогоны. `external` ключевое слово принудительно запустит тест безусловно (независимо от значения `--cache_test_results`) . См. Конвенции тегов в Энциклопедии тестов для получения дополнительной информации о конвенциях тегов, прикреплённых к целевым объектам тестов.
`target_compatible_with`	Список меток; значение по умолчанию `[]` Список `constraint_value` которые должны присутствовать в целевой платформе для этого целевого объекта, чтобы считаться совместимым. Это дополнительно к любым ограничениям, уже установленным типом правила. Если целевая платформа не удовлетворяет всем перечисленным ограничениям, целевой объект считается несовместимым. Несовместимые целевые объекты пропускаются при сборке и тестировании при расширении шаблона целевых объектов (например, `//...`, `:all`). Если несовместимые целевые объекты указаны явно в командной строке, Bazel выводит сообщение об ошибке и завершает сборку или тестирование с ошибкой. Целевые объекты, которые транзитивно зависят от несовместимых целевых объектов, сами считаются несовместимыми. Они также пропускаются при сборке и тестировании. Пустой список (по умолчанию) означает, что целевой объект совместим со всеми платформами. Все правила, кроме правил рабочей области, поддерживают этот атрибут. Для некоторых правил этот атрибут не имеет эффекта. Например, указание `target_compatible_with` для `cc_toolchain` бесполезно. См. страницу Платформы для получения дополнительной информации о пропускании несовместимых целевых объектов.

END_OF_DOCUMENT_MARKER

testonly

Булево; неконфигурируемое; по умолчанию False за исключением целей тестов и наборов тестов

Если True, только цели testonly (такие как тесты) могут зависеть от этой цели.

Эквивалентно, правило, которое не testonly, не может зависеть от правила, которое testonly.

Тесты (*_test правила) и наборы тестов (test_suite правила) по умолчанию testonly.

Этот атрибут предназначен для того, чтобы цель не включалась в двоичные файлы, выпускаемые в производство.

Поскольку testonly применяется на этапе компиляции, а не выполнения, и распространяется по дереву зависимостей, его следует применять осторожно. Например, заглушки и фиктивные объекты, которые полезны для юнит-тестов, также могут быть полезны для интеграционных тестов, использующих те же двоичные файлы, которые будут выпущены в производство, и поэтому, вероятно, не должны отмечаться как testonly. И наоборот, правила, которые опасно даже включать в проект, возможно, потому что они безусловно перезаписывают стандартное поведение, определённо должны быть помечены как testonly.

toolchains

Список меток; неконфигурируемое; по умолчанию []

Набор целей, к переменным Make которых у этой цели есть доступ. Эти цели — это экземпляры правил, предоставляющих TemplateVariableInfo или специальные цели для типов цепочек инструментов, встроенных в Bazel. К ним относятся:

@bazel_tools//tools/cpp:current_cc_toolchain
@rules_java//toolchains:current_java_runtime

Обратите внимание, что это отличается от концепции разрешения цепочки инструментов, используемой реализациями правил для платформенно-зависимой конфигурации. Вы не можете использовать этот атрибут для определения, какую конкретную cc_toolchain или java_toolchain будет использовать цель.

visibility

Список меток; неконфигурируемое; значение по умолчанию отличается

Атрибут visibility управляет тем, может ли к цели обращаться цели в других местах. См. документацию по видимости.

Для целей, объявленных непосредственно в файле BUILD или в устаревших макросах, вызываемых из файла BUILD, значение по умолчанию — пакетная default_visibility если задана, в противном случае ["//visibility:private"]. Для целей, объявленных в одном или нескольких символических макросах, значение по умолчанию всегда только ["//visibility:private"] (что делает его доступным только внутри пакета, содержащего код макроса).

Атрибуты, общие для всех правил тестов (*_test)

В этом разделе описаны атрибуты, общие для всех правил тестов.

Атрибут Описание

args

Список строк; подлежит замене $(location) и "Переменная Make", а также токенеризации оболочки Bourne; значение по умолчанию []

Аргументы командной строки, которые Bazel передает цели при её выполнении с помощью bazel test.

Эти аргументы передаются до любых значений --test_arg, указанных в командной строке bazel test.

env

Словарь строк; значения подлежат замене $(location) и "Переменная Make"; значение по умолчанию {}

Указывает дополнительные переменные среды, которые нужно задать при выполнении теста с помощью bazel test.

Этот атрибут применим только к нативным правилам, таким как cc_test, py_test, и sh_test. Он не применим к правилам тестов, определённых в Starlark. Для собственных правил Starlark вы можете добавить атрибут "env" и использовать его для заполнения TestEnvironment Provider.

env_inherit

Список строк; значение по умолчанию []

Указывает дополнительные переменные среды, которые нужно унаследовать из внешней среды при выполнении теста с помощью bazel test.

Этот атрибут применим только к нативным правилам, таким как cc_test, py_test, и sh_test. Он не применим к правилам тестов, определённых в Starlark.

size

Строка "enormous", "large", "medium", или "small"; неконфигурируемое; значение по умолчанию "medium"

Указывает "весомость" целевой задачи теста: сколько времени/ресурсов необходимо для её выполнения.

Юнит-тесты считаются "маленькими", интеграционные тесты — "средними", а тесты "от начала до конца" — "большими" или "огромными". Bazel использует размер, чтобы определить значение таймаута по умолчанию, которое можно переопределить с помощью атрибута timeout. Таймаут действителен для всех тестов в целевой задаче BUILD, а не для каждого отдельного теста. При запуске теста локально значение size дополнительно используется для планирования: Bazel пытается учитывать --local_{ram,cpu}_resources и не перегружать локальную машину запуском множества тяжёлых тестов одновременно.

Размеры тестов соответствуют следующим значениям таймаута по умолчанию и предполагаемому пиковому использованию локальных ресурсов:

Размер	ОЗУ (в МБ)	CPU (в ядрах)	Таймаут по умолчанию
маленький	20	1	короткий (1 минута)
средний	100	1	средний (5 минут)
большой	300	1	длинный (15 минут)
огромный	800	1	вечный (60 минут)

Переменная среды TEST_SIZE будет установлена в значение этого атрибута при запуске теста.

timeout

Строка "short", "moderate", "long", или "eternal"; неконфигурируемое; значение по умолчанию выводится из атрибута size теста

Сколько времени тест должен работать, прежде чем завершится.

В то время как атрибут размера теста управляет оценкой ресурсов, таймаут теста может быть установлен независимо. Если не указан явно, таймаут основан на атрибуте размера теста. Таймаут теста можно переопределить с помощью флага --test_timeout, например, для выполнения в определенных условиях, известных как медленные. Значения таймаута теста соответствуют следующим временным интервалам:

Значение таймаута	Временной интервал
короткий	1 минута
средний	5 минут
длинный	15 минут
вечный	60 минут

Для временных значений, отличных от указанных выше, таймаут теста можно переопределить с помощью флага bazel --test_timeout, например, для ручного выполнения в известных медленных условиях. Значения --test_timeout в секундах. Например, --test_timeout=120 установит таймаут теста на две минуты.

Переменная среды TEST_TIMEOUT будет установлена в значение таймаута теста (в секундах) при запуске теста.

flaky

Булево; неконфигурируемое; значение по умолчанию False

Помечает тест как ненадёжный (flaky).

При установке выполняет тест до трёх раз, помечая его как не пройденный только в случае неудачи каждый раз. По умолчанию этот атрибут устанавливается в False, и тест выполняется только один раз. Обратите внимание, что использование этого атрибута обычно не рекомендуется — тесты должны проходить надёжно, когда их утверждения соблюдаются.

shard_count

Целое число без знака, меньшее или равное 50; значение по умолчанию -1

Указывает количество параллельных фрагментов для запуска теста.

Если задано, это значение переопределит любые эвристики, используемые для определения количества параллельных фрагментов для запуска теста. Обратите внимание, что для некоторых правил тестов этот параметр может потребоваться для активации фрагментации в первую очередь. Также см. --test_sharding_strategy.

Если фрагментация теста включена, переменная среды TEST_TOTAL_SHARDS будет установлена в это значение при запуске теста.

Для фрагментации требуется, чтобы исполняемый файл теста поддерживал протокол фрагментации тестов. Если он этого не делает, то, скорее всего, выполнит каждый тест в каждом фрагменте, чего вы не хотите.

Подробные сведения о фрагментации см. в Фрагментации тестов в Энциклопедии тестов.

local

Булево; неконфигурируемое; значение по умолчанию False

Принудительно выполняет тест локально без изоляции.

Установление этого значения в True эквивалентно предоставлению "локального" тега (tags=["local"]).

Атрибуты, общие для всех правил бинарных файлов (*_binary)

В этом разделе описаны атрибуты, общие для всех правил бинарных файлов.

Атрибут Описание

Атрибут	Описание
`args`	Список строк; подвергается замене по шаблонам $(location) и "Make variable", а также токенизации оболочки Bourne; неперестраиваемый; значение по умолчанию `[]` Аргументы командной строки, которые Bazel передаст целевому объекту при его выполнении либо командой `run` либо в качестве теста. Эти аргументы передаются перед аргументами, указанными в командной строке для `bazel run` или `bazel test` команды. ПРИМЕЧАНИЕ: аргументы не передаются, если вы запускаете целевой объект вне Bazel (например, вручную выполняя исполняемый файл в `bazel-bin/`).
`env`	Словарь строк; значения подвергаются замене по шаблонам $(location) и "Make variable"; значение по умолчанию `{}` Устанавливает дополнительные переменные окружения при выполнении целевого объекта командой `bazel run`. Этот атрибут применим только к нативным правилам, таким как `cc_binary`, `py_binary`, и `sh_binary`. Он не применим к правилам исполняемых файлов, определённым в Starlark. ПРИМЕЧАНИЕ: переменные окружения не устанавливаются, когда вы запускаете целевой объект вне Bazel (например, вручную выполняя исполняемый файл в `bazel-bin/`).
`output_licenses`	Список строк; значение по умолчанию `[]` Лицензии выходных файлов, сгенерированных этим исполняемым файлом. Это часть устаревшего API лицензирования, которое Bazel больше не использует. Не используйте его.

args

Список строк; подвергается замене по шаблонам $(location) и "Make variable", а также токенизации оболочки Bourne; неперестраиваемый; значение по умолчанию []

Аргументы командной строки, которые Bazel передаст целевому объекту при его выполнении либо командой run либо в качестве теста. Эти аргументы передаются перед аргументами, указанными в командной строке для bazel run или bazel test команды.

ПРИМЕЧАНИЕ: аргументы не передаются, если вы запускаете целевой объект вне Bazel (например, вручную выполняя исполняемый файл в bazel-bin/).

env

Словарь строк; значения подвергаются замене по шаблонам $(location) и "Make variable"; значение по умолчанию {}

Устанавливает дополнительные переменные окружения при выполнении целевого объекта командой bazel run.

Этот атрибут применим только к нативным правилам, таким как cc_binary, py_binary, и sh_binary. Он не применим к правилам исполняемых файлов, определённым в Starlark.

ПРИМЕЧАНИЕ: переменные окружения не устанавливаются, когда вы запускаете целевой объект вне Bazel (например, вручную выполняя исполняемый файл в bazel-bin/).

output_licenses

Список строк; значение по умолчанию []

Лицензии выходных файлов, сгенерированных этим исполняемым файлом. Это часть устаревшего API лицензирования, которое Bazel больше не использует. Не используйте его.

Настраиваемые атрибуты

Большинство атрибутов являются "настраиваемыми", то есть их значения могут меняться при построении целевого объекта разными способами. В частности, настраиваемые атрибуты могут изменяться в зависимости от флагов, переданных в командной строке Bazel, или от того, какая зависимость требует целевого объекта. Это можно использовать, например, для настройки целевого объекта для нескольких платформ или режимов компиляции.

Следующий пример объявляет разные источники для разных архитектур целевого объекта. Запуск bazel build :multiplatform_lib --cpu x86 построит целевой объект, используя x86_impl.cc, в то время как замена --cpu arm вместо этого заставит его использовать arm_impl.cc.

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

Функция select() выбирает среди разных альтернативных значений для настраиваемого атрибута, в зависимости от того, какие критерии config_setting или constraint_value удовлетворяет конфигурация целевого объекта.

Bazel оценивает настраиваемые атрибуты после обработки макросов и перед обработкой правил (технически, между фазами загрузки и анализа). Любая обработка до оценки select() не знает, какой ветвь выбирает select(). Макросы, например, не могут изменить свое поведение в зависимости от выбранной ветви, и bazel query может только делать консервативные предположения о настраиваемых зависимостях целевого объекта. См. эту страницу часто задаваемых вопросов для получения дополнительной информации об использовании select() с правилами и макросами.

Атрибуты, помеченные как nonconfigurable в их документации, не могут использовать эту функцию. Обычно атрибут является неперестраиваемым, потому что Bazel внутренне должен знать его значение, прежде чем он сможет определить, как разрешить select().

Смотрите Настраиваемые атрибуты построения для подробного обзора.

Неявные целевые объекты вывода

Неявные выходные объекты в C++ устарели. Пожалуйста, воздерживайтесь от их использования в других языках, где это возможно. У нас пока нет пути устаревания, но они также будут постепенно устаревать.

При определении правила построения в файле BUILD вы явным образом объявляете новый, именованный целевой объект правила в пакете. Многие функции правил построения также неявным образом включают один или несколько целевых объектов выходных файлов, содержимое и значение которых зависят от правила. Например, при явном объявлении правила java_binary(name='foo', ...) вы также неявным образом объявляете целевой объект выходного файла foo_deploy.jar как член того же пакета. (Этот конкретный целевой объект — это автономный архив Java, подходящий для развертывания.)

Неявные целевые объекты вывода являются полноправными членами глобального графа целевых объектов. Как и другие целевые объекты, они строятся по запросу, либо когда они указаны в командной строке, либо когда они необходимы в качестве предварительных условий для других целевых объектов построения. Они могут быть использованы в качестве зависимостей в файлах BUILD и могут быть просмотрены в результатах инструментов анализа, таких как bazel query.

Для каждого типа правила построения документация правила содержит специальный раздел, описывающий имена и содержимое всех неявных выходных целевых объектов, включенных в объявление данного правила.

Важное, но несколько тонкое различие между двумя именованными пространствами, используемыми системой построения: метки идентифицируют цели, которые могут быть правилами или файлами, и целевые файлы могут быть разделены на целевые файлы исходных (или входных) файлов и производные (или выходные) целевые файлы. Это то, что вы можете упомянуть в файлах BUILD, построить из командной строки или просмотреть с помощью bazel query; это пространство имен целевого объекта. Каждый целевой файл соответствует одному фактическому файлу на диске (пространство имен "файловой системы"); каждый целевой объект правила может соответствовать нулю, одному или нескольким фактическим файлам на диске. Может быть файлы на диске, которые не имеют соответствующего целевого объекта; например, .o объектные файлы, созданные во время компиляции C++, не могут быть обработаны из файлов BUILD или из командной строки. Таким образом, инструмент построения может скрыть некоторые детали реализации того, как он выполняет свою работу. Это более подробно описано в справке по концепциям построения.

Если не указано иное, содержимое этой страницы лицензировано по лицензии Creative Commons Attribution 4.0, а примеры кода лицензированы по лицензии Apache 2.0. Дополнительные сведения см. в политике Google для разработчиков. Java является зарегистрированным товарным знаком Oracle и/или её аффилированных лиц.

Последнее обновление 2024-12-10 UTC.

Licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License.
https://bazel.build/versions/8.0.0/reference/be/common-definitions