| commit | 24e09f70d80c4b35547fc15668b68466f6cc889c | [log] [tgz] |
|---|---|---|
| author | gregce <gregce@google.com> | Wed Jul 01 15:18:36 2020 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Jul 01 15:19:36 2020 -0700 |
| tree | 8b76d8142180946a45a45ae9e048b00ee8ec1254 | |
| parent | 17bedb8e38d01c512a0601a8f06e9caa1a78c14e [diff] |
cquery --show_config_fragments: report fragments used by transitions Also: 1 Move collection logic into its own utility class to declutter a hard-enough-to-understand core class 2 Change the signature on Starlark transition requirements from fragment classes to the user-friendly strings they ultimately get transformed to. We do this early because transitions report options, not fragments. Trying to reduce them to fragments involves a way more complicated API with no real benefit (particularly for Starlark flags and CoreOptions, which have no fragment). This change has some quirks, which is why I changed some existing test signatures. But it's far preferable IMO to overly complicating Blaze's core APIs One of 2's particular quirks is that the final "required fragments" string isn't consistent. For example, if a rule definition requires the C++ fragment it returns "CppConfiguration", whereas if a select() or transition requires a C++ option it returns "CppOptions". This is arguably confusing. But the alternative of forcing everything into a proper Fragment (CppConfiguration) requires passing a FragmentOptions -> Fragment map to all code that computes FragmentOptions, which really complicates Blaze's APIs. Furthermore, "blaze config" outputs a mapping of fragments to FragmentOptions, which means consumers have all the info they need to connect and deduplicate. The result is a minor inconvenience that's not too invasive to Blaze and doesn't compromise ultimate correctness. In service of https://github.com/bazelbuild/bazel/issues/11258. PiperOrigin-RevId: 319306418
{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:
See CONTRIBUTING.md
