Comments 15
По своему относительно небольшому опыту работы с Bazel (я работаю в Google, но этот комментарий это моё личное мнение) могу подтвердить, что его плюсы относительно других систем сборки становятся особенно заметны, когда нужно работать с проектами, которые используют разные языки программирования: поскольку в Bazel команды для разных языков одинаковы и всё описывается декларативно, можно легко запускать тесты, собирать чужие проекты и т.д. без необходимости даже знать соответствующий ЯП, что, как мне кажется, очень здорово, особенно если не хочется тратить дни или часы на то, чтобы осваивать новые инструменты для сборки и тестирования, специфичных для конкретного языка :).
Также bazel с некоторым напильником умеет в распределенную сборку, что позволяет собирать большие проекты (даже на Go) быстрее, чем это было бы возможно локально.
Единственное, что это всё хорошо работает тогда, когда Bazel — это единственная используемая система сборки, иначе, вероятно, пользы от Bazel будет не так много.
Мне тоже показалось, что только для С++ мотивация слабовата, cmake тоже много с чем интегрируется. Основная фича — с bazel, видимо, не придётся учить новую систему сборки для Go и прочих.
Cmake как и bazel умеет свои подводные камни. например
Bazel из плюсов, при должной настройке, позволяет еще и распределенность, не даром он safe & fast.
С помощью них bazel строит граф команд, который затем кэширует и исполняет
такая же архитектура как у tensorflow. Сильно подозреваю, что их разрабатывали одни и те же люди
На мой вкус получается довольно лаконично и очень быстро. Не надо страдать и искать какой-нибудь туториал по cmake чтобы сделать какую-то тривиальную вещьСпасибо за статью (держите плюс), но по личному опыту Bazel это какое-то monstrous over-engineered нечто, к тому же написанное на джаве, разобраться в котором неподготовленному человеку едва ли получится не то что без парочки-другой туториалов, а и пол-литры. Я не большой фанат симейка, но для работы с ним в подавляющем большинстве случаев достаточно лишь документации.
Когда сталкиваюсь с проектом на базельке, первое желание — переписать всю эту
Спасибо за статью (держите плюс), но по личному опыту Bazel это какое-то monstrous over-engineered нечто, к тому же написанное на джаве, разобраться в котором неподготовленному человеку едва ли получится не то что без парочки-другой туториалов, а и пол-литры. Я не большой фанат симейка, но для работы с ним в подавляющем большинстве случаев достаточно лишь документации.
Да, согласен. В то же время лично мне очень нравится лаконичность и явность зависимостей, которые описываются в Bazel. Не уверен на счёт cmake, но Bazel умеет отвечать на вопросы, например, получить список таргетов, которые явно или неявно импортируют текущий таргет, что позволяет, например, быстро найти всё, что явно или неявно ссылается на какую-нибудь библиотеку или файл. Если весь проект собирается Bazel, то эта информация доступна без необходимости парсить содержимое исходников на .cpp и других языках и достаточно лишь просканировать BUILD-файлы.
Для небольших проектов эту информацию как правило можно получить и прямо из IDE или откуда-то ещё, но если проект очень большой и включает в себя (микро)сервисы на многих языках, то такие возможности становятся очень полезными при рефакторинге.
Bazel, в отличие от cmake не основывается на командах, а позволяет декларативно описывать зависимости через правила. По сути, правила связывают несколько артефактов с определенной операцией. С помощью них bazel строит граф команд, который затем кэширует и исполняет.Справедливости ради, современный CMake тоже склоняется к декларативному описанию проекта, пусть и командами: перечисляются таргеты, у них заполняются свойства, настраивается граф зависимостей, все. Описание сборки проекта, так сказать, в императивном стиле к нынешнему моменту считается дурным тоном. Хотя наличие такой возможности, увы, нередко провоцирует. Большое количество устаревшей документации тоже не помогает.
интеграция с другими IDE: docs.bazel.build/versions/master/ide.html
Собираем C++ с bazel