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

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

Содержание

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

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

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

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

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

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

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

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

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

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

Атрибут	Описание
`data`	Список меток; значение по умолчанию — `[]` Файлы, необходимые этому правилу во время выполнения. Может перечислять файлы или цели правил. В общем, разрешает любые цели. Выходные данные и файлы выполнения целей в атрибуте `data` должны отображаться в области `*.runfiles` любого исполняемого файла, который является выходным данным этой цели или имеет зависимость от времени выполнения от этой цели. Это может включать файлы данных или бинарные файлы, используемые при выполнении `srcs` этой цели. Более подробную информацию о том, как зависеть от файлов данных и использовать их, см. в разделе «зависимости данных». Новые правила должны определять атрибут `data`, если они обрабатывают входные данные, которые могут использовать другие входные данные во время выполнения. Функции реализации правил также должны заполнить файлы выполнения цели из выходных данных и файлов выполнения любого атрибута `data`, а также файлы выполнения из любого атрибута зависимости, который предоставляет исходный код или зависимости времени выполнения.
`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` приводит к тому, что действие или тест никогда не будут кэшироваться (удаленно или локально). `no-remote-cache` приводит к тому, что действие или тест никогда не будут кэшироваться удаленно (но могут кэшироваться локально; они также могут выполняться удаленно). Примечание: для целей этого тега дисковый кэш считается локальным кэшем, а кэши HTTP и gRPC — удаленными. Если используется комбинация локального дискового кэша и удаленного кэша (комбинированный кэш), она обрабатывается как удаленный кэш и отключается полностью, если `--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` блокирует доступ к внешней сети изнутри зоны безопасности. В этом случае разрешена только связь с локальным хостом. Этот тег имеет эффект только в том случае, если изоляция включена. `requires-fakeroot` выполняет тест или действие как uid и gid 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, но по-прежнему включать его в должным образом настроенные presubmit или непрерывные прогоны тестов. `external` ключевое слово заставит тест выполняться безусловно (независимо от значения `--cache_test_results`). См. Конвенции тегов в справочнике по тестам для получения дополнительных сведений о конвенциях тегов, прикрепленных к целевым объектам тестов.
`target_compatible_with`	Список меток; значение по умолчанию `[]` Список `constraint_value` которые должны присутствовать в целевой платформе для того, чтобы этот целевой объект считался совместимым. Это в дополнение к любым ограничениям, уже установленным типом правила. Если целевая платформа не удовлетворяет всем перечисленным ограничениям, то целевой объект считается несовместимым. Несовместимые целевые объекты пропускаются при построении и тестировании при расширении шаблона целевого объекта (например, `//...`, `:all`). При явном указании в командной строке несовместимые целевые объекты заставляют Bazel выводить ошибку и вызывать сбой построения или теста. Целевые объекты, которые транзитивно зависят от несовместимых целевых объектов, сами считаются несовместимыми. Они также пропускаются при построении и тестировании. Пустой список (который является значением по умолчанию) означает, что целевой объект совместим со всеми платформами. Все правила, кроме правил рабочей области, поддерживают этот атрибут. Для некоторых правил этот атрибут не имеет эффекта. Например, указание `target_compatible_with` для `cc_toolchain` не имеет смысла. См. страницу платформы для получения дополнительной информации о пропускании несовместимых целевых объектов.

testonly

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

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

Аналогично, правилу, которое не testonly, запрещено зависеть от любого правила, которое testonly.

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

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

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

toolchains

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

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

@bazel_tools//tools/cpp:current_cc_toolchain
@bazel_tools//tools/jdk:current_java_runtime

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

visibility

Список меток; неперенастраиваемое; значение по умолчанию default_visibility из пакета, если указано, или "//visibility:private" в противном случае

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

Атрибуты, общие для всех правил тестов (*_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"

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

Модульные тесты считаются "маленькими", интеграционные тесты "средними", а тесты end-to-end "большими" или "огромными". 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

Помечает тест как нестабильный.

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

shard_count

Неотрицательное целое число, меньшее или равное 50; значение по умолчанию -1

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

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

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

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

См. Фрагментация тестов в Энциклопедии тестов для получения подробной информации о фрагментации.

local

Булево значение; неперенастраиваемое; значение по умолчанию False

Вынуждает запуск теста локально, без изоляции.

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

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

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

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

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

args

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

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

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

env

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

Указывает дополнительные переменные среды, которые должны быть установлены при выполнении целевого объекта с помощью 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 может только делать консервативные предположения о перенастраиваемых зависимостях целевого объекта. См. эту страницу FAQ для получения дополнительной информации об использовании select() с правилами и макросами.

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

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

Неявные выходные цели

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

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

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

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

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

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

Последнее обновление: 2023-12-11 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/7.0.0/reference/be/common-definitions