Spec-Zone.ru › Bazel 6.3

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

List of labels ; optional

Файлы, необходимые этому правилу во время выполнения. Может содержать список файлов или целевых правил. Обычно позволяет использовать любые целевые файлы.

Файлы вывода по умолчанию и файлы выполнения целевых файлов в атрибуте data должны отображаться в области *.runfiles любого исполняемого файла, который выводится этим целевым файлом или имеет зависимость от него во время выполнения. Это могут включать файлы данных или исполняемые файлы, используемые при выполнении srcs этой цели. См. раздел зависимости данных для получения дополнительной информации о том, как зависеть от файлов данных и использовать их.

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

deps

List of labels ; optional

Зависимости для этой цели. Обычно следует указывать только целевые правила. (Хотя некоторые правила позволяют указывать файлы непосредственно в deps, этого следует избегать, когда это возможно.)

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

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

Чаще всего зависимость deps используется для того, чтобы один модуль мог использовать символы, определенные в другом модуле, написанном на том же языке программирования и отдельно скомпилированном. В многих случаях также разрешены зависимости между языками: например, целевой файл java_library может зависеть от кода C++ в целевом файле cc_library путем указания последнего в атрибуте deps. См. определение зависимостей для получения дополнительной информации.

licenses

List of strings; optional; nonconfigurable

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

srcs

List of labels ; optional

Файлы, обрабатываемые или включаемые этим правилом. Обычно указывает файлы непосредственно, но может указывать целевые файлы правил (например, filegroup или genrule) для включения их файлов вывода по умолчанию.

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

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

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

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

List of labels ; optional; nonconfigurable

Список сред, для которых этот целевой объект может быть скомпилирован, помимо стандартно поддерживаемых сред.

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

deprecation

String; optional; nonconfigurable

Объяснительное предупреждение, связанное с этим целевым объектом. Обычно используется для уведомления пользователей о том, что целевой объект устарел или заменён другой инструкцией, является приватным для пакета или по какой-либо причине считается вредным. Желательно включить ссылку (например, на веб-страницу, номер ошибки или примеры миграционных CL) для того, чтобы легко узнать, какие изменения требуются, чтобы избежать сообщения. Если есть новый целевой объект, который может быть использован как замена, рекомендуется просто мигрировать всех пользователей старого целевого объекта.

Этот атрибут не влияет на способ построения, но может повлиять на вывод диагностики инструмента сборки. Инструмент сборки выдает предупреждение, когда правило с атрибутом deprecation зависит от целевого объекта в другом пакете.

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

Если устаревший целевой объект зависит от другого устаревшего целевого объекта, сообщение об ошибке не выводится.

После того, как пользователи перестанут его использовать, целевой объект можно удалить.

distribs

List of strings; optional; nonconfigurable

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

exec_compatible_with

List of labels ; optional; nonconfigurable

Список constraint_values , которые должны быть присутствовать в платформе исполнения для этого целевого объекта. Это дополнительно к любым ограничениям, уже установленным типом правила. Ограничения используются для ограничения списка доступных платформ исполнения. Для получения более подробной информации, см. описание разрешения инструментальных цепочек.

exec_properties

Dictionary of strings; optional

Словарь строк, который будет добавлен к exec_properties платформы, выбранной для этого целевого объекта. См. exec_properties правила platform.

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

features

List of feature strings; optional

Функция — это строковая метка, которая может быть включена или отключена для целевого объекта. Значение функции зависит от правила.

Этот атрибут features комбинируется с атрибутом уровня пакета package features. Например, если функции ["a", "b"] включены на уровне пакета, а атрибут features целевого объекта содержит ["-a", "c"], то функции, включенные для правила, будут "b" и "c". См. пример.

restricted_to

List of labels ; optional; nonconfigurable

Список сред, для которых этот целевой объект может быть скомпилирован, вместо стандартно поддерживаемых сред.

Это часть системы ограничений Bazel. Подробнее см. compatible_with.

tags

List of strings; optional; nonconfigurable

Метки могут быть применены к любому правилу. Метки на правилах тестирования и 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 запускает тест или действие как пользователь и группа 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

List of labels ; optional

Список constraint_value , которые должны быть присутствовать в целевой платформе для данного целевого объекта, чтобы он считался совместимым. Это дополнительно к любым ограничениям, уже установленным типом правила. Если целевая платформа не удовлетворяет всем указанным ограничениям, то целевой объект считается несовместимым. Несовместимые целевые объекты пропускаются при сборке и тестировании при расширении шаблона целевых объектов (например, //..., :all). При явном указании в командной строке несовместимые целевые объекты заставляют Bazel вывести сообщение об ошибке и привести к сбоям сборки или тестирования.

Целевые объекты, которые транзитивно зависят от несовместимых целевых объектов, сами по себе считаются несовместимыми. Они также пропускаются при сборке и тестировании.

Пустой список (который является значением по умолчанию) означает, что целевой объект совместим со всеми платформами.

Все правила, кроме Правил Рабочего Пространства, поддерживают этот атрибут. Для некоторых правил этот атрибут не имеет эффекта. Например, указание target_compatible_with для cc_toolchain не имеет смысла.

Смотрите страницу Платформы для получения дополнительной информации о пропускании несовместимых целевых объектов.

testonly

Boolean; optional; default False except for test and test suite targets; nonconfigurable

Если True, то только целевые объекты типа «только для тестирования» (например, тесты) могут зависеть от этого целевого объекта.

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

Тесты (*_test правила) и наборы тестов (test_suite правила) являются «только для тестирования» по умолчанию.

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

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

toolchains

List of labels ; optional; nonconfigurable

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

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

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

visibility

List of labels ; optional; default default_visibility from package if specified, or //visibility:private otherwise; nonconfigurable

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

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

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

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

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization

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

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

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

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

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

env_inherit

List of strings; optional

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

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

size

String "enormous", "large" "medium" or "small", default is "medium"; optional; nonconfigurable

Указывает «весомость» целевого объекта теста: сколько времени/ресурсов требуется для его выполнения.

Тесты юнит-тестирования считаются «маленькими», тесты интеграции — «средними», а тесты конечного пользователя — «большими» или «огромными». 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

String "short", "moderate", "long", "eternal" (with the default derived from the test's size attribute); nonconfigurable

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

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

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

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

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

flaky

Boolean; optional; default False; nonconfigurable

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

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

shard_count

Non-negative integer less than or equal to 50; optional

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

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

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

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

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

local

Boolean; default False; nonconfigurable

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

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

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

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

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

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization; nonconfigurable

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

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

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

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

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

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

output_licenses

List of strings; optional

Лицензии выходных файлов, создаваемых этим бинарным файлом. Это часть устаревшего 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-07-25 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/6.3.0/reference/be/common-definitions

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API