Bazel - относительно новая система сборки

[Majestio]

Всем привет!

Совершенно случайно столкнулся с инфой по этой системе, и меня она очень впечатлила. Решил с вами поделиться этой инфой. Может кто уже пользует во всю и поделится впечатлениями и лайфхаками...



Разработчик: Google
Первый выпуск: 2015 год
Сайт: https://bazel.build

Почему эта штука меня очень заинтересовала:

• Это полноценная система сборки, на не как, например CMake или Meson, которые являются генераторами build-систем
• Имеет гораздо более лаконичный язык своих конфигурационных файлов нежели CMake
• Имеет свою собственную мощную систему отслеживания зависимостей (с возможностью скачки из репозитариев при необходимости), чуть слабее конечно чем Conan
• Своя очень мощная подсистема кэширования для обеспечения максимизации скорости инкрементальных сборок
• Поддерживает мультиязычные проекты (имеется ввиду, когда в проекте отдельные модули собираются на разных языках программирования)
• Поддерживает распределенную сборку на базе gRPC, наибольший прирост производительности - при использовании Docker-образов
• Кросс-платформанность - одна конфигурация проекта на все поддерживаемые платформы

Это только малая часть, которую я выяснил при первом знакомстве
В общем, приглашаю к обсуждению всех, кому такое интересно. И особенно тех, кто этим уверено пользуется!

[sharky72]

У нас на проекте используется для сборки. Но я пока сам в нем еще разбираюсь. А зависимости все равно conan

Сообщение отредактировано: sharky72 - 23.12.25, 11:12

[Majestio]

Цитата sharky72 @ 23.12.25, 11:11

А зависимости все равно conan

Да, я чуть позже прочёл про это. Просто у Conan репозитарий куда больше, грех не пользоваться.
Но, на сколько я понял, и Bazel, и Conan - вполне себе неплохо чувствуют, в "кооперации"?

[D_KEY]

CMake + Conan фактически стандарт сейчас. Кроме легаси или простых проектов.
Система сборки, которая могла бы это заменить, должна как-то иметь возможность лёгкой миграции, а так же давать какие-то существенные преимущества...

[Majestio]

Цитата D_KEY @ 23.12.25, 18:48

CMake + Conan фактически стандарт сейчас. Кроме легаси или простых проектов.
Система сборки, которая могла бы это заменить, должна как-то иметь возможность лёгкой миграции, а так же давать какие-то существенные преимущества...

Ну н счёт преимуществ - я там мало-мало перечислил, просто почитать внимательнее надо.
А вот про кооперацию Bazel и Conan я писал ранее.

[sharky72]

Цитата Majestio @ 23.12.25, 11:18

Цитата sharky72 @ 23.12.25, 11:11

А зависимости все равно conan

Да, я чуть позже прочёл про это. Просто у Conan репозитарий куда больше, грех не пользоваться.
Но, на сколько я понял, и Bazel, и Conan - вполне себе неплохо чувствуют, в "кооперации"?

Да. Именно в такой связке и работаем. У базеля очень интересный подход к сборке. Местами мне даже нравится. Но иногда задолбаешься указывать правильные зависимости, откуда брать либы, откуда хидерры, чего можно дать тесту, чего низзя. Для кого твоя сборка видна, а для кого нет. В каждую папочку BUILD файл, где все прописваешь. При правильном построении иерархии сборки большого проекта - очень удобно.
Синтаксис своего языка Starlark близок к питону. Так что питоноводам легко въехать.
Я его первый раз сосбно на нынешнем проекте и увидел. До того в основном conan+cmake. И да. Все в докере.

Сообщение отредактировано: sharky72 - 23.12.25, 21:37

[negram]

Bazel, на мой взгляд, имеет чудовищный порог вхождения. Что-то сложнее сборка-линковка становится кошмаром. Зато, если в нём разобраться, отдача получается просто огромной. Это имеет смысл для очень сложных проектов, навроде Google Chrome и Envoy - где он как-раз и используется.
Например, такие штуки, которые мне нравятся:

- сборка всегда в сендбоксе, при этом есть несколько вариантов сендбоксов - от подмены ENV до запуска в докере
- возможность делать распределённую сборку, причём, можно как на ферме серверов, так и peer-to-peer
- можно организовать репозиторий в виде модулей (это даже в его best practices), и переиспользовать модули, просто сославшись на git repo+path
- конкретно с плюсами, достаточно просто подключить любой autotools (едрён-батон, такие до сих пор встречаются!)/cmake-либу, если нет подготовленного модуля
- "пресеты" для разных конфигураций - можно задать набор правил (линковщик/сборщик/сендбокс/флаги/toolchain) и использовать его либо условно (где собираем - linux/mac), либо явно

Кроме того, Bazel - это не только про C++, он позиционируется как сборщик-полиглот, и может переварить любой язык. Например, на предыдущем месте, он собирал и Typescript и Python. Короче, безумно мощная штука, и безумно сложная поначалу. Ещё огорчает их подход к апдейтам - очень часто ломается обратная совместимость, хотя это постоянно обещают пофиксить))

Сообщение отредактировано: negram - 06.01.26, 10:14

[Majestio]

negram, пасип за инфу! =)

[kolobok0]

Цитата negram @ 06.01.26, 09:44

Bazel, на мой взгляд, имеет чудовищный порог вхождения...отдача получается просто огромной. Это имеет смысл для очень сложных проектов,...

- сборка всегда в сендбоксе, при этом есть несколько вариантов сендбоксов - от подмены ENV до запуска в докере
- возможность делать распределённую сборку, причём, можно как на ферме серверов, так и peer-to-peer
- можно организовать репозиторий в виде модулей (это даже в его best practices), и переиспользовать модули, просто сославшись на git repo+path
- конкретно с плюсами, достаточно просто подключить любой autotools (едрён-батон, такие до сих пор встречаются!)/cmake-либу, если нет подготовленного модуля
- "пресеты" для разных конфигураций - можно задать набор правил (линковщик/сборщик/сендбокс/флаги/toolchain) и использовать его либо условно (где собираем - linux/mac), либо явно
....позиционируется как сборщик-полиглот,...огорчает их подход к апдейтам - очень часто ломается обратная совместимость, хотя это постоянно обещают пофиксить))

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

спасибо
ЗЫ ЗЫ
Правда ещё лучше - привести сравнительный анализ. Это ещё больше даёт ответов и понимания о чём речь, плюс раскрывает немного сам опыт пользователя и глубину норы .

Сообщение отредактировано: kolobok0 - 06.01.26, 10:44

[sharky72]

Как и сказал negram, bazel не для маленьких проектов. Но довольно интересен.

[D_KEY]

negram,

[kolobok0]

Цитата sharky72 @ 06.01.26, 12:36

Как и сказал negram, bazel не для маленьких проектов. Но довольно интересен.

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

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


С уважением
(круглый)

[negram]

Цитата kolobok0 @ 06.01.26, 10:41

Правда ещё лучше - привести сравнительный анализ. Это ещё больше даёт ответов и понимания о чём речь, плюс раскрывает немного сам опыт пользователя и глубину норы .

У меня маленький опыт с базелем - я, в основном, работал с ним в Envoy. И вряд-ли тут у кого-то есть большой, кажется, но я был бы рад об кого-нибудь проверить свои впечатления.

Ну давайте попробуем. Пожалуй, начну немного с истории.

Сначала был компилятор (ну, и линковщик, хотя он вероятно чуть позже появился). Потом решили, что есть некий граф, по которому можно собирать приложение - сделали Makefile: стало гораздо лучшее. Потом придумали, что toolchain надо как-то конфигурировать - появился autotools, потом cmake (и ещё дюжина малоизвестных аналогов), которые позволяли генерить скрипты для make/ninja. Были кстати, ещё cons/scons, mozbuild и подобные - обходились даже без make, но кажется они не прижились. На этом этапе встаёт вопрос пере-использования компонент.

Прежний ответ unix-like: ставим в ОС dev-пакеты, их подхватывают cmake и прочие, и радуемся. Это поднимает 3 вопроса:
- а если нет прав что-то ставить?
- а что, если таких пакетов вообще нет?
- ну теперь надо поддерживать рандомную версию рандомной либы - это боль, нафига оно, если проект не открытый, например?

Добавляем ещё компонент: менеджер пакетов (conan, hunter).

(вообще, все эти проблемы можно было закрыть с помощью shell-скрипта, но это само собой порождает кучу проблем ).

А! Ещё есть вопрос - а если cmake в системе не совместим с нашим сценарием сборки?


Вот это вкратце, что такое Bazel - это воплощение всех этих шагов/вопросов в одном месте.
Стоит так же добавить, что это проект Гугла, в котором есть свои нюансы, навроде того, что там есть армия из десятков тысяч инженеров. Для них важно, чтоб работало у всех и это было сложно сломать, тк если есть возможность что-то сделать не так, на таком масштабе сделают. Мне кажется, ещё полезно (как минимум, интересно) почитать философию, которая лежит в основе: https://abseil.io/resources/swe-book/html/ch18.html


С похожими идеями есть ещё Buck (https://buck2.build/) от фейсбука, которые утверждают, что пофиксили какие-то проблемы Bazel. К тому же Buck написан на Rust, вместо Java.

1. Вопрос версии сборщика

В целом, в bazel принято ставить в систему bazelisk (https://github.com/bazelbuild/bazelisk). И тогда, в корне репы кладётся файлик (https://github.com/envoyproxy/envoy/blob/main/.bazelversion), и так мы убеждаемся, что версия bazel - та, что нам надо.

В CMake можно прописать minimal required version, с обещанием не ломать совместимость, но тут отличие - bazelisk скачает правильную версию и сам её запустит.


2. Выбор пакетов

Тут есть 2 варианта: во-первых, если репозиторий модулей (https://registry.bazel.build/all-modules). Кажется, пакетов тут сильно меньше, чем в conan, но и репозиторий более молодой (кажется год-два назад появился). Если чего-то нет, см “во-вторых”.

Во-вторых, можно подключить foreign lib (https://registry.bazel.build/modules/rules_foreign_cc) - то есть описать правила сборки/линковки с либой. В этом месте, отличие от cmake-ка опять же, что либа будет скачена сама.

Тут я встретил проблему с гибкостью: если либа очень кастромная, может быть больно (см “герметичность”). Дело в том, что в юниксах принято инсталлить библиотечки в 3 места:
- заголовки
- данные линквки (иногда отсутствует)
- либа (.a/.so)

И foreign_cc поощряют, если библиотека следует этому паттерну, но я, например, пытался слинковаться с YTSaurus SDK, который был открыт по принципу “кидаем в opensource что есть, пусть сами фиксят), и там ничего такого нет. Настраивать include/link path было сложно, потому-что на одну эту SDK путей нереально много и из-за герметичности, не так-то просто пройтись по дереву ФС и составить список папочек, где лежат .a-файлы. Задача решается, но пришлось попотеть. C Cmake-ом вышло проще, тк SDK нативно поддерживает cmake.

Пример ссылок на удалённые репозитории: https://github.com/envoyproxy/envoy/blob/ma...y_locations.bzl


Тут же можно упомянуть, про переиспользование частей репозитория, но лучше почитать доку: https://bazel.build/concepts/build-ref. Тут кажется, сравнивать не с чем - я такой фичи не видел. На этом построена сборка XDS-сервисов, например.


3. Платформы/конфигурации:
https://bazel.build/extending/platforms
https://bazel.build/extending/config
https://bazel.build/extending/toolchains

Вот эти штуки позволяют включать/выключать части проекта под определёнными платформами. Это похоже, на toolchain/defines в CMake, но на мой взгляд чутка более удобно.
С точки зрения пользователя, можно посмотреть вот тут как настраивается сборка в зависимости от выбранной/задетекченной конфигурации:
https://github.com/envoyproxy/envoy/blob/main/.bazelrc


4. Герметичность

Вот это, кажется, одно из самых opinionated мест bazel.

Герметичность означает отсутствие внешних зависимостей (не описанных в правилах сборки).

Все скрипты сборки не видят и не могут зависеть от того, что установленно в системе. Всё, что используется должно быть явным образом объявлено (например, с помощью того-же toolchain). Это не заметно, если используются нативные bazel-инструкции, но если например, хочется использовать protoc из системы - придётся заморочиться с написанием своего toochain. Из-за этого в скриптах сборки, например, нет средств работы с ФС - просто нельзя что-то взять и прочитать из рандомного места ФС, запустить скрипт из домашней папки и тп.


Это не заметно на совсем маленьких проектах - где нет необходимости запустить какой-нибудь кастомный скрипт/генератор.

Это обескураживает и обезоруживает, если это надо - потому-что это легко делается в том же cmake, да и где угодно. Но.

Это оказывается чрезвычайно мощным инструментом, если хочется делать воспроизводимые сборки и убедиться, что сборка работает на масштабах тысяч разработчиков. Иначе, нет никакой гарантии, что Вася поставит что-то не то, пропустит важный шаг в инструкции “как собирать” и тп.
Это позволяет легко сделать удалённый запуск сборки - нет зависимостей от конкретной системы, значит запускать можно на любой! В теории, даже не родной - ведь у нас есть концепт платформы, который позволит даже делать кросс-компиляцию (но это место я не проверял)

Bazel сам контролирует инструменты, что использует. Описать свой тулчеин, поначалу сложно - синтаксис (или семантика?) непривычный.


5. Стабильность

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

Этот момент смягчается тем, что используем bazelisk и фиксируем версию bazel: у всех всегда всё работает. Больно тем, кто сопровождает систему сборки.


6. Starlark

Вся сборка описывается на языке Starlark. Это действительно подмножество Python - разработчики взяли синтаксис питона и заимплементили его, с оговорками.

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


7. Go

Казалось бы. Go сделан в гугле, Bazel сделан гуглом - они должны идеально работать друг с другом. И, насколько я могу судить, этим пользуются, но я не смог.

С одной стороны, для меня была killer-фича: в базеле можно сделать авторизацию, при скачивании go-модуля (модули в Go - это git-репозитории, причём, по-дефолту используется git+https, и сделать авторизацию возможно, но гемморойно; а в базеле легко). Это важно, когда работаешь с приватными репозиториями/модулями.

Но оказалось (либо я что-то не понял), что в bazel, придётся прописать не только используемые пакеты, но ещё и описать все транзитивные зависимости. Это для меня как-то было черезчур, показалось, что проще сделать правило, что запускает go build и берёт артифакт, чем нативно встраивать его в bazel.

Всё-таки подозреваю, что я что-то не так понял…


8. Отдельный сервер-процесс.

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


9. Дебаг

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

Но с другой стороны, в cmake приходится дебажить, а тут надо знать куда/как смотреть

Сообщение отредактировано: negram - 08.01.26, 10:40

[Majestio]

Супер-обзор!!!