Veröffentlichung des Open-Source-Build-Tools , entwickelt von Ingenieuren bei Google und verwendet für den Aufbau der meisten internen Projekte des Unternehmens. Bazel ermöglicht den Build-Prozess, indem es die erforderlichen Compiler und Tests ausführt. Es unterstützt das Erstellen und Testen von Code in Java, C++, Objective-C, Python, Rust, Go und vielen anderen Sprachen sowie das Erstellen mobiler Anwendungen für Android und iOS. Der Projektcode unter der Apache 2.0-Lizenz.
Änderungen an dieser neuen Version sind signifikant und beinhalten inkompatible Änderungen. Ab Bazel 2.0 werden standardmäßig die Modi „—incompatible_remap_main_repo“ (Namensreferenzen und @-Referenzen verweisen jetzt auf ein Repository) sowie „—incompatible_disallow_dict_lookup“ (Verwendung von nicht-hashbaren Schlüsseln) aktiviert.
„—incompatible_remove_native_maven_jar“ und „—incompatible_prohibit_aapt1“. Unter den weiteren Änderungen:
- Im Team wurde experimentelle Unterstützung für das neue Ausgabeformat „proto“ (—output=proto) hinzugefügt, das standardmäßig deaktiviert ist (—incompatible_proto_output_v2) und eine kompaktere Datenpräsentation ermöglicht;
- Ein neues Flag „—incompatible_remove_enabled_toolchain_types“ wurde hinzugefügt, das es ermöglicht, das Feld PlatformConfiguration.enabled_toolchain_types zu entfernen;
- Schutz gegen Paket-Uploads hinzugefügt, bei denen zyklische symbolische Links verwendet werden, um Pfade aufzulösen;
- Die Verwendung des Flags „—disk_cache“ mit externen gRPC-Caches wurde implementiert;
- Ein verbessertes Layer, das die Dateien ~/.bazelversion und die Umgebungsvariable $USE_BAZEL_VERSION verarbeitet, wurde in das Debian-Paket und den binären Installer aufgenommen;
- Im Zuge der Vorbereitung zur Verschiebung von Dateien mit Manifesten in die Kategorie veralteter Funktionen wurde das Flag „—experimental_skip_runfiles_manifests“ hinzugefügt.
Zu den Hauptmerkmalen von Bazel gehören hohe Geschwindigkeit, Zuverlässigkeit und die Wiederholbarkeit des Build-Prozesses. Um die Build-Geschwindigkeit zu maximieren, nutzt Bazel aktiv Techniken zur Cache-Verwendung und zur Parallelisierung des Build-Prozesses. In BUILD-Dateien sind alle Abhängigkeiten vollständig definiert, auf deren Basis Entscheidungen zur Wiederherstellung der Komponenten nach Änderungen getroffen werden (es werden nur die geänderten Dateien neu gebaut) und der Build-Prozess parallelisiert wird. Das Werkzeug garantiert ebenfalls die Wiederholbarkeit des Builds, d.h. das Ergebnis des Projekts auf dem Rechner des Entwicklers wird vollständig mit dem Build auf externen Systemen, wie z.B. Continuous Integration-Servern, übereinstimmen.
Im Gegensatz zu Make und Ninja verfolgt Bazel einen höherwertigen Ansatz zur Erstellung von Build-Regeln. Anstatt Befehlsbindungen an die zu erstellenden Dateien zu definieren, verwendet es abstraktere Bausteine wie "Kompilierung einer ausführbaren Datei in C++", "Erstellung einer C++-Bibliothek" oder "Ausführung eines Tests für C++" sowie die Definition von Ziel- und Build-Plattformen. In der BUILD-Datei werden die Projektkomponenten als eine Kombination aus Bibliotheken, ausführbaren Dateien und Tests beschrieben, ohne ins Detail über einzelne Dateien und Compileraufrufe zu gehen. Zusätzliche Funktionalitäten werden über ein Erweiterungsmechanismus bereitgestellt.
Die Verwendung einheitlicher Build-Dateien für verschiedene Plattformen und Architekturen wird unterstützt. Zum Beispiel kann eine Build-Datei ohne Änderungen sowohl für das Serversystem als auch für mobile Geräte verwendet werden. Das Build-System wurde ursprünglich für die optimale Erstellung von Google-Projekten konzipiert, einschließlich der Erstellung sehr großer Projekte und solcher mit Code in mehreren Programmiersprachen, die umfangreiche Tests erfordern und für mehrere Plattformen gebaut werden.
Quelle: opennet.ru
