Войти
 | |
| Разработчик (и) | |
|---|---|
| Первоначальный выпуск | Март 2015 г. |
| Стабильный выпуск | 3.1.0 / 21 апреля 2020 г.; 5 месяцев назад (2020-04-21) |
| Репозиторий |  |
| Написано на | Java |
| Операционная система | Кросс-платформенная |
| Лицензия | Apache License 2.0 |
| Веб-сайт | bazel.build |
Bazel - это бесплатное программное обеспечение, позволяющее автоматизировать построение и тестирование программного обеспечения. Компания Google использует инструмент сборки Blaze для внутренних целей и выпустила часть инструмента Blaze с открытым кодом под названием Bazel, названную анаграммой Blaze. Bazel был впервые выпущен в марте 2015 года и получил статус бета-версии к сентябрю 2015 года.
Подобен инструментам сборки, таким как Make, Apache Ant или Apache Maven, Bazel строит программные приложения из исходного кода, используя набор правил. Правила и макросы создаются на языке Starlark (ранее называвшемся Skylark), диалекте Python. Существуют встроенные правила для создания программного обеспечения, написанного на языках программирования из Java, C, C ++, Go, Python, Objective-C и Bourne shell скрипты. Bazel может создавать пакеты программных приложений, подходящие для развертывания в операционных системах Android и iOS.
При разработке Bazel упор был сделан на скорость сборки, правильность и воспроизводимость. Инструмент использует распараллеливание, чтобы ускорить части процесса сборки. Он включает язык запросов Bazel, который можно использовать для анализа зависимостей сборки в сложных графах сборки.
Одна из целей Bazel - создать систему сборки, в которой целевые входы и выходы сборки полностью определены и поэтому точно известны системе сборки. Это позволяет более точно анализировать и определять устаревшие артефакты сборки в графике зависимостей системы сборки. Повышение детерминированности анализа графа зависимостей приводит к потенциальному сокращению времени сборки за счет исключения повторного выполнения ненужных целей сборки. Надежность сборки повышается за счет исключения ошибок, когда цели сборки могут зависеть от устаревших входных артефактов.
Для более точного анализа графа зависимостей Bazel использует дайджесты содержимого, а не временные метки на основе файлов. Временные метки файлов обычно используются для обнаружения изменений в таких инструментах, как Make или Apache Ant. Отметки времени могут быть проблематичными, если сборки распределены по нескольким хостам из-за проблем с синхронизацией часов. Одна из целей Bazel - обеспечить распределенную и параллельную сборку в удаленной облачной инфраструктуре. Bazel также предназначен для масштабирования до очень больших репозиториев сборки, которые могут быть непрактичными для загрузки на рабочий компьютер отдельного разработчика.
Bazel предоставляет инструменты, которые помогают разработчикам создавать идентичные побитно воспроизводимые выходные данные сборки. Реализованные в Bazel правила избегают типичных ошибок, таких как встраивание временных меток в сгенерированные выходные данные, чтобы гарантировать совпадение дайджеста контента. Это, в свою очередь, позволяет системе сборки надежно кэшировать (memoize ) выходные данные промежуточных шагов сборки. Кроме того, воспроизводимая сборка позволяет обмениваться промежуточными результатами сборки между командами или отделами в организации, используя выделенные серверы сборки или распределенные кэши. Поэтому Bazel особенно хорошо подходит для крупных организаций и программных проектов, которые имеют значительное количество зависимостей сборки. Детерминированная сборка и способность точно анализировать входные и выходные артефакты сборки по графу зависимостей позволяют выполнять параллельное выполнение шагов сборки.
Bazel расширяется с помощью специального языка программирования Starlark. Старларк использует синтаксис, который является подмножеством синтаксиса языка программирования Python. Однако Starlark не реализует многие языковые функции Python, такие как возможность изменять коллекции или получать доступ к файловому вводу-выводу, чтобы избежать расширений, которые могут создавать побочные эффекты или создавать выходные данные сборки, неизвестные самой системе сборки. Такие побочные эффекты могут потенциально привести к некорректному анализу графа зависимостей сборки.
Bazel был разработан как многоязычная система сборки. Многие часто используемые системы сборки разработаны с предпочтением определенного языка программирования. Примеры таких систем включают Ant и Maven для Java, Leiningen для Clojure, sbt для Scala и т. Д. На многоязычном языке project, объединение отдельных систем сборки и достижение описанных выше преимуществ скорости сборки и корректности может быть трудным и проблематичным.
Bazel также обеспечивает выполнение сборки в песочнице. Это можно использовать, чтобы убедиться, что все зависимости сборки указаны правильно и сборка не зависит, например, от библиотек, установленных только локально на рабочем компьютере разработчика. Это помогает гарантировать, что сборки остаются переносимыми и могут выполняться в других (удаленных) средах.
Системы сборки, наиболее похожие на Базель, - это Штаны, Бак и Пожалуйста. Брюки и Бак преследуют те же цели технического дизайна, что и Bazel, и были вдохновлены системой сборки Blaze, используемой внутри Google. Blaze также является предшественником Bazel. Bazel, Pants, Buck и Please приняли Starlark в качестве парсера файла BUILD в соответствии с его синтаксисом файла BUILD. Независимо разработанные системы сборки с аналогичными целями эффективного анализа графа зависимостей и автоматического отслеживания артефактов сборки были реализованы в таких системах сборки, как tup.
Одна из ключевых функций, отличающих Bazel от других системы сборки - это использование песочницы для шагов компиляции. Когда Bazel выполняет отдельную компиляцию, он создает новый каталог и заполняет его символическими ссылками на явные входные зависимости для правила. Для таких языков, как C / C ++, это обеспечивает значительную безопасность для включения файлов заголовков: это гарантирует, что разработчик знает о файлах, которые используются при компиляции, и предотвращает неожиданное включение файла заголовка с таким же именем из другой каталог include.
Такой подход «песочницы» приводит к проблемам с общими инструментами сборки, что приводит к ряду обходных путей, необходимых для правильной компиляции кода для разных архитектур. Например, при выполнении отдельной компиляции для архитектур Mac / Darwin компилятор записывает входные пути в символы SO и OSO в двоичном файле Mach-O, что можно увидеть с помощью команды типа nm -a mybinary | grep SO. Эти пути нужны для поиска символов при отладке. В результате сборки в Bazel должны исправлять скомпилированные объекты постфактум, пытаясь исправить проблемы, связанные с путями, которые возникли при построении песочницы, с помощью таких флагов, как -fdebug-prefix-mapи -oso_prefix., последний, который стал доступен только недавно, как XCode 11.0. Аналогичная обработка должна происходить на этапах компоновки, переписывая значения rpath в библиотеках общих объектов с помощью команды типа install_name_tool.
Старый логотип Bazel С момента первоначального выпуска Bazel логотипом была зеленая буква " б »стилизован под стебель базилика с двумя листьями.
5 июля 2017 года блог Bazel объявил о новом логотипе, состоящем из трех зеленых строительных блоков, расположенных в форме сердца.
Портал компьютерного программирования 