Avoid building android R class ijar / header jar It is already ignored and the real jar used as the compileTime jar in AndroidCommon. It's only used by the ide-resolve output group. The real jar is pretty close to the header jar in terms of content (field inits deleted). Tradeoff: The real jar is ~33% bigger (w/ same compression level), vs save build time and space by skipping the hjar actions and artifacts. At android_binary level, the hjar action can take ~40 seconds in some cases. At the library level, the hjar time is pretty tiny. hjars are not compressed. We could compress the real jars to make up for the extra 30% size (and beat the hjar size), but that adds ~25% elapsed time to do the compression (e.g., 10s vs 7.5s). Compression can shrink the jar 2-3x (37MB vs 100MB). -- MOS_MIGRATED_REVID=131588283
{Fast, Correct} - Choose two
Bazel is a build tool that builds code quickly and reliably. It is used to build the majority of Google‘s software, and thus it has been designed to handle build problems present in Google’s development environment, including:
A massive, shared code repository, in which all software is built from source. Bazel has been built for speed, using both caching and parallelism to achieve this. Bazel is critical to Google's ability to continue to scale its software development practices as the company grows.
An emphasis on automated testing and releases. Bazel has been built for correctness and reproducibility, meaning that a build performed on a continuous build machine or in a release pipeline will generate bitwise-identical outputs to those generated on a developer's machine.
Language and platform diversity. Bazel's architecture is general enough to support many different programming languages within Google, and can be used to build both client and server software targeting multiple architectures from the same underlying codebase.
Find more background about Bazel in our FAQ.