Значительное изменение версии связано с добавлением изменений, нарушающих обратную совместимость. Начиная с Bazel 2.0 включены по умолчанию режимы «—incompatible_remap_main_repo» (ссылки по имени и через @ теперь ссылаются на один репозиторий), «—incompatible_disallow_dict_lookup»_(применение нехешируемых ключей), «—incompatible_remove_native_maven_jar» и «—incompatible_prohibit_aapt1». Среди других изменений:
- В команде aquery появилась экспериментальная поддержка новой редауции формата вывода «proto» (—output=proto), которая пока отключена по умолчанию (—incompatible_proto_output_v2) и обеспечивает более компактное представление данных;
- Добавлен флаг «—incompatible_remove_enabled_toolchain_types», позволяющий удалить поле PlatformConfiguration.enabled_toolchain_types;
- Добавлена защита от загрузки пакетов, при загрузке которых при раскрытии путей используются цикличные символические ссылки;
- Реализована возможность использования флага «—disk_cache» с внешними кэшами gRPC;
- В пакет для Debian и бинарный инсталлятор включена улучшенная прослойка, обрабатывающая файлы ~/.bazelversion и переменную окружения $USE_BAZEL_VERSION;
- В рамках подготовки к переводу файлов с манифестом runfiles в категорию устаревших возможностей добавлен флаг «—experimental_skip_runfiles_manifests».
Среди отличительных особенностей Bazel выделяются высокая скорость, надёжность и повторяемость процесса сборки. Для достижения высокой скорости сборки в Bazel активно применяются техники кэширования и распараллеливания процесса сборки. В BUILD-файлах обязательно полностью определены все зависимости, на основе которых принимаются решения по пересборке компонентов после внесения изменений (пересобираются только изменившиеся файлы) и распараллеливания процесса сборки. Инструментарий также гарантирует повторяемость сборки, т.е. результат сборки проекта на машине разработчика будет полностью совпадать со сборкой на сторонних системах, таких как серверы непрерывной интеграции.
В отличие от Make и Ninja в Bazel применяется более высокоуровневый подход к построению правил сборки, при котором вместо определения привязки команд к собираемым файлам производится применение более абстрактных готовых блоков, таких как «сборка исполняемого файла на языке С++», «сборка библиотеки на C++» или «запуск теста для C++», а также определение целевых и сборочных платформ. В текстовом файле BUILD компоненты проекта описываются как связка библиотек, исполняемых файлов и тестов, без детализации на уровне отдельных файлов и команд вызова компилятора. Дополнительная функциональность реализуется через механизм подключения расширений.
Поддерживается использование единых сборочных файлов для разных платформ и архитектур, например, один файл сборки без изменений может применяться как для серверной системы, так и для мобильного устройства. Сборочная система изначально спроектирована для оптимальной сборки проектов Google, в том числе сборки очень больших проектов и проектов, содержащих код на нескольких языках программирования, требующих расширенного тестирования и собираемых для нескольких платформ.
Источник: http://www.opennet.ru/opennews/art.shtml?num=52090
