| commit | 4dc0d119a6f4901aa8353e75941c19205542743e | [log] [tgz] |
|---|---|---|
| author | Googler <twigg@google.com> | Wed Sep 13 14:04:10 2023 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Sep 13 14:05:44 2023 -0700 |
| tree | 2aafbaecbe7411591bbbf305779b29fcd32b8387 | |
| parent | a2f5e820494494f5152d81be9e992f3e0aa9ef38 [diff] |
Replace EXPLICIT_IN_OUTPUT_PATH and Fragment.getOutputDirectoryName w/ Fragment.processForOutputDirectoryMnemonic This better consolidates all the code that computes the output path mnemonic (both the explicit parts like k8-fastbuild and the ST-hash) into one place, OutputPathMnemonicComputer. Note that the determination of the baseline options is still done in BuildConfigurationFunction and passed in. In the new system, Fragment override a function called processForOutputDirectoryMnemonic and have access to an addToMnemonic function, which explicitly adds an entry to the mnemonic, and markAsExplicitInOutputPath, which excludes an option from consideration by ST-hash. This also resolves a code maintenance issue with the old version where options had to be marked as EXPLICIT_IN_OUTPUT_PATH in the FragmentOptions while also having the exact logic for how they were represented in Fragment. Now, both the declaration and naming logic can be co-located. As a mild cleanup, the cpu is no longer explicitly added to the output path as part of CppConfiguration fragment but instead is now always the first part of the mnemonic. This (along with the consolidation done by this CL in general) should simplify later work on including the `--platforms` as explicitly part of the output path. The exact order of mnemonic parts will scramble slightly. The mnemonic now always starts with [cpu/platform]-[compilation_mode]-[platform_suffix] versus the old behavior of the cpu only being added as part of the CppFragment logic and [compilation_mode]-[platform_suffix] coming later. However, the new order should be more consistent and explainable in general. There is a slight regression in behavior for `--output_directory_naming_scheme=legacy` as the code for updating `affected by starlark transition` after a transition cannot yet know if the changed options will be explicit in the output path. Thus, all changes variables are included in the ST-hash. (This is actually a reversion back to much older behaviors and hopefully most users have migrated to using `--output_directory_naming_scheme=diff_against_dynamic_baseline`.) RELNOTES: Change output paths to consistently start with [cpu]-[compilation_mode] along with other cleanups to output path generation logic. PiperOrigin-RevId: 565154905 Change-Id: Ic3501b768a0d77d1f0811cc68ec91ece332cd5df
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
