External dependencies should have a features = ["-please_disable_this_feature", ..."] switch

[aaron-michaux]

Description of the feature request:

Some external dependencies are already "bazelified", such as grpc, which is a blessing and a curse. The problem is that your toolchain is going to pass down all the flags for all your enabled features, including things like "-D_FORTIFY_SOURCE", and "-Werror", and then your dependency will fail to build.

When supplying your own BUILD file for a non-bazelified repo, you can switch things off:

package(features = ["-fortify", "-warnings"])

If I could do something like this:

    http_archive(
        name = "com_github_grpc_grpc",
        urls = [
            "https://github.com/grpc/grpc/archive/refs/tags/v1.39.1.tar.gz",
        ],
        strip_prefix = "grpc-1.39.1",
        sha256 = "024118069912358e60722a2b7e507e9c3b51eeaeee06e2dd9d95d9c16f6639ec",
        features = ["-fortify", "-warnings"],
    )

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

Obviously, with all the code in the world, in various states of shininess, it becomes important to be able to control which flags are used to build the code. And that shouldn't create a "lowest-common-denominator" burden for downstream code. In theory, I should be able to be as pedantic as I want, and still be able to build and link to code written by more pragmatically oriented development teams.

Which operating system are you running Bazel on?

Ubuntu 20.04

What is the output of bazel info release?

release 4.2.1

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 master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

https://stackoverflow.com/questions/63588902/in-bazel-how-to-prevent-some-c-compiler-flags-from-passing-to-external-depend

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

No response

[meteorcloudy]

/cc @oquenchil

[meteorcloudy]

This can be solved with a module extension when the community migrates to Bzlmod.

You can have a module extension (e.g. provided by rules_cc) to generate a repo for each C++ module, which contains a list of features that should be enabled/disabled. For example, for C++ module "foo":
In foo's MODULE.bazel file:

feature_ext = use_extension("@rules_cc//:feature_extension.bzl", 'feature_extension")
use_repo(feature_ext, "cc_toolchain_features_for_foo")

At the beginning of foo's BUILD files

load("@cc_toolchain_features_for_foo/:features.bzl", feature_list)
package(features = feature_list)
cc_library(
...

Then the root module can use the same module extension to override what features should be given to a specific module.
The root project's MODULE.bazel

bazel_dep(name = "foo", version = "x.x.x")
feature_ext = use_extension("@rules_cc//:feature_extension.bzl", 'feature_extension")
feature_ext.add_feature("foo", "fortify")
feature_ext.remove_feature("foo", "warning")

[aaron-michaux]

The problem statement document (https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.xxnnwabymk1v) is interesting, and helps shed light on what I'm dealing with.

Is there any solution -- hackish or otherwise -- that I can implement in bazel 4.2.1?

[meteorcloudy]

Well, you can certainly patch your external dependencies, right?

[aaron-michaux]

Okay. I was hoping for something a little less "all-in".

[meteorcloudy]

@aaron-michaux 😅 Sorry, I cannot think of any better solution.

[fmeum]

This bazel-discuss thread has another example of a situation where this would be useful: https://groups.google.com/g/bazel-discuss/c/YiFe0KR77xM/m/pBfxl5C2BAAJ