Каковы различия между Bazel и Gradle?

Ответ 1

Отказ от ответственности: я работаю над Bazel, и я не знаком с Gradle. Однако один из моих коллег написал сравнение двух систем, которое я перефразирую здесь:

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

Gradle выполняет те же принципы, что и Bazel, т.е. команда Gradle уделяет большое внимание производительности (инкрементные сборки, параллельная конфигурация и исполнение, демон Gradle), правильность (контент- (богатая поддержка декларативного синтаксиса, управление версиями зависимостей, явно объявленные зависимости). И Базел уважает потребность в гибких макетах проекта.

Нюанс заключается в том, что Gradle хочет продвигать хорошую практику, в то время как Bazel хочет его потребовать. Gradle нацелен на середину между опытом Ant (свобода определять собственную структуру проекта с некогерентными результатами) и опыт Maven (применяемые передовые методы, не имеющие возможности для различных потребностей проекта). Bazel полагает, что гибкая поддержка проекта возможна без ущерба для сильных гарантий, которые позволяют использовать его мощные рабочие процессы.

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

Gradle Обзор

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

Gradle подчеркивает следующие функции:

• Легкая миграция из других систем. Gradle легко вмещает любую организацию проекта, чтобы легко реализовать произвольные структуры рабочих процессов. Он изначально понимает задачи Ant и изначально интегрируется с репозиториями Maven и Ivy.
• Высокоразвитая сценаристская модель. Пользователи реализуют всю логику сборки, написав сценарии Groovy. "Строить" - это просто выполнение последовательностей общих задач, зависящих от зависимостей, которые по существу являются открытыми, переопределяемыми, расширяемыми определениями методов.
• Богатое управление зависимостями. Проверенные зависимости могут быть объявлены и автоматически организованы из внешних репозиториев кода, локальных файловых систем и других проектов Gradle. Выходы сборки также могут быть автоматически опубликованы в хранилищах и в других местах.
• Плотно интегрированная система плагинов. Плагины - это просто пулы задач, организованных для облегчения желаемого рабочего процесса. Многие из основных функций Gradle s "core" фактически реализованы через плагины (например, Java, Android). Плагины взаимодействуют (по своему усмотрению) с логикой build script. Плагины имеют глубокий доступ к основным структурам данных Gradle.

Обзор Bazel

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

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

Bazel подчеркивает следующие возможности:

• Корректность. Конструкции Bazel предназначены для того, чтобы всегда производить правильный выход, период. Если два пользователя вызывают одну и ту же сборку с одной и той же фиксацией с теми же флагами Bazel на разных машинах, они будут видеть одинаковые результаты. Инкрементные сборки так же надежно правильны, как и чистые сборки, что делает их по существу ненужными.
• Производительность. Сборка предназначена для выполнения так быстро, насколько это возможно, исходя из имеющихся ресурсов. Задачи столь же параллелизуемы, как позволяют их сети зависимостей. Ненужная работа никогда не выполняется (т.е. "Современные" задачи всегда пропускаются). Естественно, что работа над удаленными исполнителями может быть выполнена для преодоления локальных ограничений на машины.
• воспроизводимости. Любой экземпляр сборки может быть точно воспроизведен в любой среде. Например, если в отчете об ошибке говорится, что версия X программного обеспечения Y не работает в производственной среде Z, разработчик может с уверенностью воссоздать ее на своей собственной машине с уверенностью, что они отлаживают одно и то же.

Ответ 2

Как ссылки на статьи, как правило, умирают, вот краткое изложение Gradle Team views на Bazel (большинство из них непосредственно сняты из статьи, который был опубликован в марте 2015 года):

Он был разработан для решения проблемы, уникальной для Google; массивная монолитная кодовая база (сотни миллионов LOC).

Преимущество параллелизации, которое в настоящее время предоставляет Bazel, будет соответствовать "нашей новой конфигурации и модели компонентов" (см. дату статьи здесь).

Bazel не имеет декларативного языка сборки высокого уровня, который делает сборку простой в использовании для разработчиков. В Google это может быть компенсировано специализированной сервисной командой, которая владеет инструментом сборки.

Bazel не создан для расширяемости (хотя команда разработчиков Bazel с тех пор возражает против этого, уверяя, что они работают над расширяемостью).

Скорость оптимизирована вокруг идеи, что все транзитивные зависимости хранятся в одном большом репо; все библиотеки и инструменты проверяются в этом центральном репозитории. Большинство предприятий имеют более распределенные требования к управлению зависимостями.

Bazel только * nix, он не работает в Windows. Это устраняет большое количество потенциальных Предприятий.

Отсутствие экосистемы плагинов.