Spec-Zone.ru › Bazel 6.4

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

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

Содержание

  • Токенизация оболочки 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

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

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

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

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

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

Этот атрибут не влияет на способ построения, но может повлиять на диагностические сообщения инструмента сборки. Инструмент сборки выводит предупреждение, когда правило с атрибутом 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 атрибут комбинируется с features атрибутом уровня пакета package. Например, если функции ["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 ключевое слово блокирует доступ к внешней сети изнутри изолированной среды. В этом случае разрешается только общение с 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, но всё ещё включать его в правильно настроенные presubmit или непрерывные тесты.
  • external ключевое слово принудительно выполнит тест (независимо от значения --cache_test_results).
См. Конвенции тегов в Энциклопедии тестов для получения дополнительных сведений о конвенциях тегов, присоединённых к тестовым целевым объектам.
target_compatible_with

List of labels ; optional

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

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

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

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

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

END_OF_DOCUMENT_MARKER
testonly

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

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

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

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

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

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

toolchains

List of labels ; optional; nonconfigurable

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

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

Обратите внимание, что это отличается от понятия разрешения инструментальных цепочек, которое используется реализациями правил для платформенно-зависимой конфигурации. Вы не можете использовать этот атрибут для определения того, какую конкретную 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 Provider.

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

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

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

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

Размер ОЗУ (в МБ) Процессор (в ядрах процессора) Стандартная временная задержка
небольшой 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-10-20 по 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.4.0/reference/be/common-definitions

Spec-Zone.ru

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