| commit | 50dc4463b8daeceb01403c3390532a8953ce24bc | [log] [tgz] |
|---|---|---|
| author | twigg <twigg@google.com> | Thu Mar 10 14:59:52 2022 -0800 |
| committer | Copybara-Service <copybara-worker@google.com> | Thu Mar 10 15:01:14 2022 -0800 |
| tree | bb4c1d6cfa532aef283378807ab1a010705f61f5 | |
| parent | f45a3f600e4312c2eb987658fdca4eae0ad13ec6 [diff] |
Adding BASELINE_CONFIGURATION precomputed value for reading by BuildConfigurationFunction Add `--experimental_output_directory_naming_scheme` to toggle between legacy scheme (which `affected by starlark transition` to determine what options to diff) and diff_against_pure (which instead diffs the current configuration against some single configuration for the build deemed as the pure configuration). Currently, the 'baseline' configuration is the top-level configuration determined after command-line arguments are parsed. Note that this CL just demonstrates the necessary infrastructure and test changes so that this baseline configuration can be safely 'summoned' by BuildConfigurationFunction. The ConfigCommandTest was changed to no longer rely on configurations surviving across multiple builds (as, when the top-level options change, the pure configuration precomputed value is re-set/changed causing the old BuildconfigurationValues to be invalidated and disappear from view of ConfigCommand). Related to https://github.com/bazelbuild/bazel/issues/14023 Discussion of why setBaselineConfiguration is called in BuildView.update: It is somewhat of a compromise (as it is shortly after the actual BuildOptions is first available and at a nexus point where a lot of commands fan-in and fan-out): An earlier place could be in BuildTool, right after the BuildOptions is constructed; however, 1. that isn't much earlier and still in a weird place 2. A bunch more test cases bypasses BuildTool (whereas only a few like BuildViewTestCase bypass BuildView) It could potentially be earlier if we are willing to either: A. construct the BuildOptions earlier B. store a different, more raw value then use a SkyFunction to turn that into a BuildOptions Note that earlier would likely still have issues with test frameworks all needing tweaks (that is probably my main critique of having so many varieties of test cases: each one mocks differently so mocking new Skyframe state has to be tailored to each variety) PiperOrigin-RevId: 433859815
{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
