sortie des outils d'assemblage ouverts , développé par les ingénieurs de Google et utilisé pour assembler la plupart des projets internes de l'entreprise. Bazel construit le projet en exécutant les compilateurs et les tests nécessaires. Il prend en charge la création et le test de code en Java, C++, Objective-C, Python, Rust, Go et de nombreux autres langages, ainsi que la création d'applications mobiles pour Android et iOS. Code de projet sous licence Apache 2.0.
Un changement de version important implique l’ajout de modifications qui rompent la compatibilité ascendante. À partir de Bazel 2.0, les modes suivants sont activés par défaut : "—incompatible_remap_main_repo" (liens par nom et via @ désormais liés au même référentiel), "—incompatible_disallow_dict_lookup"_(utilisation de clés non hachables),
"--incompatible_remove_native_maven_jar" et "--incompatible_prohibit_aapt1". Les autres changements incluent :
- Dans une équipe un support expérimental est apparu pour une nouvelle édition du format de sortie « proto » (-output=proto), qui est actuellement désactivé par défaut (-incompatible_proto_output_v2) et fournit une présentation plus compacte des données ;
- Ajout de l'indicateur "--incompatible_remove_enabled_toolchain_types" pour supprimer le champ PlatformConfiguration.enabled_toolchain_types ;
- Ajout d'une protection contre le chargement de packages qui utilisent des liens symboliques cycliques lors du chargement de chemins lors de leur développement ;
- Implémentation de la possibilité d'utiliser l'indicateur « --disk_cache » avec les caches gRPC externes ;
- Le paquet Debian et l'installateur binaire incluent une couche améliorée qui gère les fichiers ~/.bazelversion et la variable d'environnement $USE_BAZEL_VERSION ;
- En préparation à la dépréciation des fichiers manifestes runfiles, l'indicateur "--experimental_skip_runfiles_manifests" a été ajouté.
Parmi les caractéristiques distinctives de Bazel figurent la vitesse élevée, la fiabilité et la répétabilité du processus d'assemblage. Pour atteindre une vitesse de construction élevée, Bazel utilise activement des techniques de mise en cache et de parallélisation pour le processus de construction. Les fichiers BUILD doivent définir entièrement toutes les dépendances, sur la base desquelles les décisions sont prises pour reconstruire les composants après les modifications (seuls les fichiers modifiés sont reconstruits) et paralléliser le processus d'assemblage. L'outillage garantit également un assemblage reproductible, c'est-à-dire le résultat de la construction d'un projet sur la machine du développeur sera complètement identique à la construction sur des systèmes tiers, tels que des serveurs d'intégration continue.
Contrairement à Make et Ninja, Bazel utilise une approche de niveau supérieur pour créer des règles d'assemblage, dans laquelle, au lieu de définir la liaison des commandes aux fichiers en cours de construction, des blocs plus abstraits prêts à l'emploi sont utilisés, tels que « construire un fichier exécutable dans C++», «construire une bibliothèque en C++» ou «exécuter un test pour C++», ainsi qu'identifier les plates-formes cibles et de construction. Dans le fichier texte BUILD, les composants du projet sont décrits comme un ensemble de bibliothèques, de fichiers exécutables et de tests, sans détailler au niveau des fichiers individuels et des commandes d'appel du compilateur. Des fonctionnalités supplémentaires sont implémentées via le mécanisme de connexion des extensions.
L'utilisation de fichiers d'assemblage uniques pour différentes plates-formes et architectures est prise en charge ; par exemple, un fichier d'assemblage sans modifications peut être utilisé à la fois pour un système serveur et un appareil mobile. Le système de build est conçu dès le départ pour créer de manière optimale des projets Google, y compris des projets de très grande envergure et des projets contenant du code dans plusieurs langages de programmation, nécessitant des tests approfondis et conçus pour plusieurs plates-formes.
Source: opennet.ru