Wydanie systemu kompilacji Bazel 2.0

Do dyspozycji udostępnienie otwartych narzędzi montażowych Bazel 2.0, развиваемого инженерами из Google и используемого для сборки большинства внутренних проектов данной компании. Bazel обеспечивает сборку проекта, запуская необходимые компиляторы и тесты. Поддерживается сборка и тестирование кода на Java, C++, Objective-C, Python, Rust, Go и многих других языках, а также сборка мобильных приложений для Android и iOS. Код проекта dystrybuowane przez na licencji Apache 2.0.

Значительное изменение версии связано с добавлением изменений, нарушающих обратную совместимость. Начиная с 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».

Do wyróżniających cech Bazela należy duża szybkość, niezawodność i powtarzalność procesu montażu. Aby osiągnąć dużą szybkość kompilacji, Bazel aktywnie wykorzystuje techniki buforowania i równoległości w procesie kompilacji. Pliki BUILD muszą w pełni definiować wszystkie zależności, na podstawie których podejmowane są decyzje o przebudowie komponentów po dokonaniu zmian (przebudowywane są tylko zmienione pliki) i zrównoleglać proces montażu. Oprzyrządowanie zapewnia także powtarzalność montażu, tj. wynik zbudowania projektu na maszynie dewelopera będzie całkowicie identyczny z kompilacją na systemach innych firm, takich jak serwery ciągłej integracji.

W przeciwieństwie do Make i Ninja, Bazel stosuje podejście wyższego poziomu do budowania reguł asemblera, w którym zamiast definiować powiązanie poleceń z budowanymi plikami, używane są bardziej abstrakcyjne, gotowe bloki, takie jak „budowanie pliku wykonywalnego w C++”, „budowanie biblioteki w C++” czy „uruchamianie testu dla C++”, a także identyfikacja platform docelowych i kompilacji. W pliku tekstowym BUILD komponenty projektu są opisane jako zbiór bibliotek, plików wykonywalnych i testów, bez opisywania szczegółów na poziomie poszczególnych plików i poleceń wywołania kompilatora. Dodatkowa funkcjonalność realizowana jest poprzez mechanizm łączenia rozszerzeń.

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

Źródło: opennet.ru

Dodaj komentarz