release of open assembly tools , developed by engineers from Google and used to assemble most of the company's internal projects. Bazel builds the project by running the necessary compilers and tests. It supports building and testing code in Java, C++, Objective-C, Python, Rust, Go and many other languages, as well as building mobile applications for Android and iOS. Project code licensed under Apache 2.0.
A significant version change involves the addition of changes that break backward compatibility. Starting with Bazel 2.0, the following modes are enabled by default: “—incompatible_remap_main_repo” (links by name and via @ now link to the same repository), “—incompatible_disallow_dict_lookup”_ (use of unhashable keys),
"--incompatible_remove_native_maven_jar" and "--incompatible_prohibit_aapt1". Other changes include:
- Team experimental support has appeared for a new edition of the “proto” output format (-output=proto), which is currently disabled by default (-incompatible_proto_output_v2) and provides a more compact presentation of data;
- Added the "--incompatible_remove_enabled_toolchain_types" flag to remove the PlatformConfiguration.enabled_toolchain_types field;
- Added protection against loading packages that use cyclic symbolic links when loading paths when expanding them;
- Implemented the ability to use the “--disk_cache” flag with external gRPC caches;
- The Debian package and binary installer includes an improved layer that handles ~/.bazelversion files and the $USE_BAZEL_VERSION environment variable;
- In preparation for the deprecation of runfiles manifest files, the flag "--experimental_skip_runfiles_manifests" has been added.
Among the distinguishing features of Bazel stand out high speed, reliability and repeatability of the assembly process. To achieve high build speed, Bazel actively uses caching and parallelization techniques for the build process. BUILD files must fully define all dependencies, on the basis of which decisions are made on rebuilding components after making changes (only changed files are rebuilt) and parallelizing the build process. The toolkit also guarantees assembly repeatability, i.e. the result of building the project on the developer's machine will completely match the build on third-party systems, such as continuous integration servers.
Unlike Make and Ninja, Bazel uses a higher-level approach to constructing build rules, in which, instead of defining the binding of commands to the files being built, more abstract ready-made blocks are used, such as “building an executable file in C ++”, “building a library in C++" or "test run for C++", as well as defining target and build platforms. In the BUILD text file, project components are described as a bunch of libraries, executable files and tests, without detailing at the level of individual files and compiler call commands. Additional functionality is implemented through the mechanism for connecting extensions.
The use of single assembly files for different platforms and architectures is supported; for example, one assembly file without changes can be used for both a server system and a mobile device. The build system is designed from the ground up to optimally build Google projects, including very large projects and projects that contain code in multiple programming languages, require extensive testing, and are built for multiple platforms.
Source: opennet.ru