Отказ от ответственности: я работаю над Bazel, и я не очень хорошо знаком с Gradle. Однако один из моих коллег написал сравнение двух систем, которое я перефразирую здесь:
Базель и Градл подчеркивают различные аспекты опыта сборки. В какой-то степени их приоритеты несовместимы - стремление Gradle к гибкости и ненавязчивости ограничивает ограничения, которые он может накладывать на структуру сборки, в то время как стремление Bazel к надежности и производительности обязательно накладывает не подлежащие обсуждению ограничения.
Gradle ценит те же принципы, что и Bazel, т. Е. Команда Gradle уделяет большое внимание производительности (инкрементные сборки, распараллеленная конфигурация и выполнение, демон Gradle), корректности (проверка на основе содержимого «в актуальном состоянии») и воспроизводимости. (богатая поддержка декларативного синтаксиса, управление версиями зависимостей, явно объявленные зависимости). И Базель уважает необходимость гибких макетов проекта.
Нюанс в том, что Gradle хочет продвигать хорошую практику, в то время как Bazel хочет ее требовать. Gradle стремится к промежуточному положению между опытом Ant (свобода определения собственной структуры проекта с непоследовательными результатами) и опытом Maven (применение передовых методов работы без возможности варьировать потребности проекта). Базель считает, что гибкая поддержка проекта возможна без ущерба для сильных гарантий, которые обеспечивают его мощные рабочие процессы.
Ни одна из этих философий не является более «правильной» - какой инструмент лучше всего подходит для проекта, зависит от ценностей этого конкретного проекта.
Обзор Gradle
Gradle - это очень гибкая система, которая позволяет пользователям легко создавать законченные, надежные потоки сборки с минимальными ограничениями на организацию своих проектов. Это достигается за счет предоставления мощных строительных блоков (например, автоматического отслеживания и извлечения зависимостей, тесно интегрированной поддержки плагинов) с универсальным, полным по Тьюрингу интерфейсом сценариев, который может комбинировать эти блоки по желанию пользователей.
Gradle подчеркивает следующие особенности:
- Легкая миграция из других систем. Gradle легко приспосабливается к любой организации проекта, чтобы легко реализовать произвольные структуры рабочего процесса. Он изначально понимает задачи Ant и интегрируется с репозиториями Maven и Ivy.
- Высоко расширяемая модель сценариев. Пользователи реализуют всю логику сборки, написав скрипты Groovy. «Сборка» - это просто выполнение последовательных зависимостей общих задач, которые по существу являются открытыми, переопределяемыми, расширяемыми определениями методов.
- Богатое управление зависимостями. Версионные зависимости могут быть объявлены и автоматически размещены во внешних хранилищах кода, локальных файловых системах и других проектах Gradle. Выходные данные сборки также могут автоматически публиковаться в репозиториях и других местах.
- Плотно интегрированная система плагинов. Плагины - это просто наборы задач, организованных для облегчения желаемого рабочего процесса. Многие из «основных» функций Gradle на самом деле реализованы с помощью плагинов (например, Java, Android). Плагины тесно взаимодействуют (по своему усмотрению) с логикой сценария сборки. Плагины имеют глубокий доступ к основным структурам данных Gradle.
Базель Обзор
Bazel возникла из-за необходимости надежного и эффективного создания внутренних проектов Google. Поскольку среда разработки Google необычайно велика и сложна, Bazel предлагает необычайно сильные гарантии целостности своих сборок и необычайно низкие накладные расходы на их выполнение.
Это обеспечивает основу для мощных рабочих процессов разработки, построенных вокруг воспроизводимых сборок, где «сборка» становится абстрактной сущностью, на которую можно ссылаться, повторять, передавать на разные машины и передавать произвольным программам и службам, так что каждый экземпляр известен как точно так же.
Базель подчеркивает следующие особенности:
- Корректность. Базельские сборки спроектированы так, чтобы всегда давать правильный результат, период. Если два пользователя вызовут одну и ту же сборку при одном и том же коммите с одинаковыми флагами Bazel на разных машинах, они увидят одинаковые результаты. Инкрементные сборки так же надежны, как и чистые сборки, что делает последние по существу ненужными.
- Производительность. Сборки предназначены для максимально быстрого выполнения с учетом доступных им ресурсов. Задачи распараллеливаются настолько, насколько позволяют их цепочки зависимостей. Ненужная работа никогда не выполняется (т. Е. «Актуальные» задачи всегда пропускаются). Естественно, работа может передаваться удаленным исполнителям для преодоления локальных ограничений машин.
- Воспроизводимость. Любой экземпляр сборки может быть точно воспроизведен в любой среде. Например, если в сообщении об ошибке говорится, что версия X программного обеспечения Y дает сбой в производственной среде Z, разработчик может точно воссоздать ее на своем компьютере с уверенностью, что они отлаживают одно и то же.
Поскольку ссылки на статьи, как правило, умирают, вот краткое изложение взглядов команды Gradle на Базель (большинство из них непосредственно взяты из статьи, опубликованной в марте 2015 года):
Это было разработано, чтобы решить проблему, уникальную для Google; массивная монолитная кодовая база (сотни миллионов LOC).
Преимущество параллелизации, предоставляемое Bazel в настоящее время, будет соответствовать «нашей новой конфигурации и модели компонентов» (имейте в виду дату статьи здесь).
Bazel не имеет декларативного языка сборки высокого уровня, который делает сборку простой в использовании для разработчиков. В Google это может быть компенсировано специализированной сервисной командой, которая владеет инструментом сборки.
Bazel не создан для расширяемости (хотя команда разработчиков Bazel с тех пор противостоит этому с уверенностью, что работает над расширяемостью).
Скорость оптимизируется вокруг идеи, что все транзитивные зависимости хранятся в одном большом репо; все библиотеки и инструменты зарегистрированы в этом центральном хранилище. Большинство предприятий имеют более распределенные требования к управлению зависимостями.
Базель только * nix, он не работает в Windows. Это исключает большое количество потенциальных предприятий.
Нет плагин экосистемы.
источник
Gradle в основном используется в экосистеме JVM (Java, Ggroovy, Scala, Kotlin ...). Если ваш проект находится в этой области, и вы должны задать вопрос, Gradle или Maven будет лучшим выбором. Чтобы устранить неполадки сборки Gradle, вы будете бороться только с экосистемой Java и JVM.
В основе Bazel есть способность обнаруживать инкрементные изменения (а также распределенный кеш сборок) и позволяет вам реагировать, применять плагины / правила для достижения инкрементных сборок. Для настройки и поддержки этого требуется немного знаний CPP, Java и Python (Skylark), а также знания системного администратора. Опять же, если вам придется задать вопрос, я думаю, что Gradle или Maven будет более дешевой инвестицией. С помощью Bazel вы можете создавать любые языки, в зависимости от того, что вы определяете, больше возможностей, но с затратами.
источник