tree 8b76d8142180946a45a45ae9e048b00ee8ec1254
parent 17bedb8e38d01c512a0601a8f06e9caa1a78c14e
author gregce <gregce@google.com> 1593641916 -0700
committer Copybara-Service <copybara-worker@google.com> 1593641976 -0700

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