search

bazelbuild / bazel

a fast, scalable, multi-language and extensible build system
https://bazel.build
Apache License 2.0
22.99k stars 4.03k forks source link

Allow for local copts overrides to bzlmod modules. #20049

Open asa opened 10 months ago

asa commented 10 months ago

Description of the feature request:

If I use a bzlmod module from the BCR, I am stuck with the flags the original author used, and their choices around warnings and error handling. In my teams we treat warnings as errors and use clang to compile c++, and so others choices around (often GCC) flags often need to be overriden when we use such packages. Currently I have been moving override flags into system wide locations in .bazelrc, which is too open. People on slack mentioned a pattern to have a --per_file_copt, which they apply to all external/.c files to disable warnings for instance. A better option would be to be able to override/filter any and all flags in an upstream bazel module, perhaps directly at definition. Others mentioned a --per_repo_copts flag as a new feature that would take care of these needs. Another mentioned having a callback where we could have access to the flags in the upstream definition, and be able to do starlark things to that set of flags before it was applied in the local instantiation of the repo.

Which category does this issue belong to?

Configurability

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

Overriding upstream bazel module components to make selective changes before they are used in my bazel workspace.

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

6.3.2

gregestren commented 10 months ago

Can you clarify

I am stuck with the flags the original author used

?

Do you mean --copt or the copt attribute on cc_* or both?

i.e. if you're depending on the module, is the Bazel flag --copt being set automatically somewhere?

asa commented 10 months ago

I mean the original Copts flags on the cc_* rules.

gregestren commented 10 months ago

Makes sense. What makes the --per_file_copt approach too open?

We're exploring ideas of better containing which settings apply to which module. But I think the current thinking is to give modules more control over how they're built to build them more consistently. We'd have to be careful that overrides don't override intentional invariants the module authors want to enforce for their code.