Veröffentlichung des Bazel 2.0 Build-Systems

Verfügbar Freigabe offener Montagewerkzeuge Bazel 2.0, entwickelt von Ingenieuren von Google und verwendet, um die meisten internen Projekte des Unternehmens zusammenzustellen. Bazel erstellt das Projekt, indem er 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. Projektnummer vertrieben von lizenziert unter Apache 2.0.

Eine wesentliche Versionsänderung beinhaltet das Hinzufügen von Änderungen, die die Abwärtskompatibilität beeinträchtigen. Ab Bazel 2.0 sind die folgenden Modi standardmäßig aktiviert: „—inkompatible_remap_main_repo“ (Links nach Namen und über @ verweisen jetzt auf dasselbe Repository), „—inkompatible_disallow_dict_lookup“_(Verwendung von nicht-hashbaren Schlüsseln),
„--inkompatible_remove_native_maven_jar“ und „--inkompatible_prohibit_aapt1“. Zu den weiteren Änderungen gehören:

• In einer Mannschaft eine Anfrage Es wurde experimentelle Unterstützung für eine neue Ausgabe des „Proto“-Ausgabeformats (-output=proto) angezeigt, das derzeit standardmäßig deaktiviert ist (-inkompatible_proto_output_v2) und eine kompaktere Darstellung der Daten bietet.
• Das Flag „--inkompatible_remove_enabled_toolchain_types“ wurde hinzugefügt, um das Feld „PlatformConfiguration.enabled_toolchain_types“ zu entfernen.
• Schutz gegen das Laden von Paketen hinzugefügt, die beim Laden von Pfaden beim Erweitern zyklische symbolische Links verwenden;
• Die Möglichkeit implementiert, das Flag „--disk_cache“ mit externen gRPC-Caches zu verwenden;
• Das Debian-Paket- und Binärinstallationsprogramm enthält eine verbesserte Ebene, die ~/.bazelversion-Dateien und die Umgebungsvariable $USE_BAZEL_VERSION verarbeitet;
• Als Vorbereitung auf die Abschaffung der Runfiles-Manifestdateien wurde das Flag „--experimental_skip_runfiles_manifests“ hinzugefügt.

Zu den besonderen Merkmalen von Bazel zählen die hohe Geschwindigkeit, Zuverlässigkeit und Wiederholbarkeit des Montageprozesses. Um eine hohe Build-Geschwindigkeit zu erreichen, nutzt Bazel aktiv Caching- und Parallelisierungstechniken für den Build-Prozess. BUILD-Dateien müssen alle Abhängigkeiten vollständig definieren, auf deren Grundlage Entscheidungen getroffen werden, Komponenten nach vorgenommenen Änderungen neu zu erstellen (nur geänderte Dateien werden neu erstellt) und den Montageprozess zu parallelisieren. Die Werkzeugausstattung gewährleistet außerdem eine wiederholbare Montage, d. h. Das Ergebnis der Erstellung eines Projekts auf dem Computer des Entwicklers ist völlig identisch mit dem Ergebnis der Erstellung auf Systemen von Drittanbietern, beispielsweise auf Continuous-Integration-Servern.

Im Gegensatz zu Make und Ninja verwendet Bazel einen übergeordneten Ansatz zum Erstellen von Assemblerregeln, bei dem, anstatt die Bindung von Befehlen an die zu erstellenden Dateien zu definieren, abstraktere vorgefertigte Blöcke verwendet werden, wie zum Beispiel „Erstellen einer ausführbaren Datei in“. C++“, „Erstellen einer Bibliothek in C++“ oder „Durchführen eines Tests für C++“ sowie Identifizieren von Ziel- und Build-Plattformen. In der BUILD-Textdatei werden die Projektkomponenten als eine Reihe von Bibliotheken, ausführbaren Dateien und Tests beschrieben, ohne auf die Ebene einzelner Dateien und Compiler-Aufrufbefehle näher einzugehen. Zusätzliche Funktionalität wird durch den Mechanismus zum Anschließen von Erweiterungen implementiert.

Die Verwendung einzelner Assembly-Dateien für verschiedene Plattformen und Architekturen wird unterstützt; beispielsweise kann eine Assembly-Datei ohne Änderungen sowohl für ein Serversystem als auch für ein mobiles Gerät verwendet werden. Das Build-System ist von Grund auf darauf ausgelegt, Google-Projekte optimal zu erstellen, einschließlich sehr großer Projekte und Projekte, die Code in mehreren Programmiersprachen enthalten, umfangreiche Tests erfordern und für mehrere Plattformen erstellt wurden.

Source: opennet.ru