Expose enabled/requested features in `FeatureConfigurationForStarlark` to Starlark

armandomontanez commented 1 week ago

Description of the feature request:

I have a need to introspect the current feature configuration of the current toolchain from starlark, but currently that's not possible:

is_enabled() and is_requested() both are considered private API:

Error in is_enabled: file '//pw_toolchain/cc/current_toolchain:enabled_toolchain_feature.bzl' cannot use private API

Enabled and requested feature names are not exposed to Starlark as list members of a FeatureConfiguration provider.

Which category does this issue belong to?

C++ Rules

What underlying problem are you trying to solve with this feature?

In short, I'm exposing the current toolchain configuration so it can be communicated for use in config_settings as a more granular way to control select() statements throughout a build. This is meant to be a more powerful alternative to compiler_flag in @bazel_tools. This would, for example, allow toolchains to communicate the flavor of compiler and linker in parallel via sentinel features, which is important for some configurations where clang might be used to compile while gcc is used to link.

More context at https://pwbug.dev/361229275.

Which operating system are you running Bazel on?

No response

What is the output of `bazel info release`?

No response

If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

No response

What's the output of `git remote get-url origin; git rev-parse HEAD` ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

tpudlik commented 1 week ago

@trybka @comius FYI

tpudlik commented 1 week ago

@armandomontanez correct me if I'm wrong, but it seems like the implementation here would be pretty straightforward? So the question is mostly whether a PR exposing this information would be approved.

armandomontanez commented 1 week ago

Partially. The bigger motivator was just to have an associated issue to track this and provide background. The implementation itself will likely be trivial.

armandomontanez commented 3 days ago

It looks like this is supported through cc_common.is_enabled(). I still think it might be a good idea to expose is_enabled() on FeatureConfiguration itself since that's a little more intuitive.

Also, exposing enabled_features (and potentially requested_features) as a list of strings seems both harmless and intuitive, so I think that's worth discussing still.

bazelbuild / bazel