Mechanism for enabling optional features at build time, e.g. http2 support in libcurl

[jbms]

While this may apply to any use of bazel, it is particularly relevant in the context of dependencies on third-party libraries.

libcurl, for example, has many optional features that must be enabled at build time, such as support for http2 or brotli/zstd content-encoding.

This could be done with build_setting, but then all required options are essentially the responsibility of the top-level project. There is no good way for a library to say that it needs libcurl with http2 support. While a transition would sort of allow that, what we want is to build a single copy of curl with all of the required features, not multiple copies of curl with different sets of features.

See discussion on slack: https://bazelbuild.slack.com/archives/C014RARENH0/p1702790320489509?thread_ts=1702671095.223429&cid=C014RARENH0

[fmeum]

I think that this could be solved by adding a module to the registry that allows optional capabilities (im avoiding the term feature here as it has a different meaning within Bazel) to be registered and marked as required via a module extension.

Modules could use the extension to indicate that they optionally provide a certain capability (e.g. curl could register http2). Then every module could indicate that it requires the http2 capability of curl. curl could then use that information to either enable or disable the capability, based on whether any module requested it and what is the default. The root module would be given a way to override all the capabilities. Capabilities would be automatically namespaced per module, so they can have short names just like features.

This should even suffice to implement https://docs.google.com/document/d/132vEDnQZY0PtF9ko6HoLQ2dqk6meZnSrUfc1gsKuBkk/edit?usp=drivesdk: rules_cc could just offer capabilities that enumerate the C++ standards and in the end choose the highest one that has been required.

Cc @Wyverald @meteorcloudy

[jbms]

This also seems related to the Cargo "feature" mechanism: https://doc.rust-lang.org/cargo/reference/features.html

In general it seems that this need not be tied to bzlmod at all --- instead it may be better as a general bazel mechanism related to build_setting, some sort of optional_feature that can be listed as a dependency in some way.

[meteorcloudy]

I really like what @fmeum has proposed here. And I wonder maybe we can we provide some general framework for implementing "optional capabilities" so that all modules requiring this can share some infrastructure?

[fmeum]

@meteorcloudy I will prototype this and share it for review, in the form of a module independent of the Bazel core.

[meteorcloudy]

in the form of a module independent of the Bazel core.

That's exactly what I had in mind, thank you!! 🙏🏼