Duplicate --config=foo produces a seemingly pointless warning

[mehrdadn]

As of Bazel 3.2.0, if you have build --config=foo in multiple places (like .bazelrc and ~/.bazelrc), bazel build produces the following warning:

WARNING: The following configs were expanded more than once: [foo]. For repeatable flags, repeats are counted twice and may lead to unexpected behavior.

It's not clear under which scenario --config=foo may be "repeatable" or produce "unexpected behavior". To my understanding, such a thing cannot happen, and hence the warning seems like a bug. There does not appear to be any conflict in the requested flags. Could the warning be removed?

[ulfjack]

In most cases, it's safe to have the same flag multiple times. The only (?) case where flags can produce unexpected results if expanded multiple times are 'list' options, such as --copt. The bazel invocation bazel build --copt=-DFOO --copt=-DFOO is not the same as bazel build --copt=-DFOO. Bazel does not know what these flags mean and will not de-duplicate them. In this case, switching from once to twice means that you'll get cache misses on all caches (in-memory, local action cache, remote action cache). In general, this means you get separate cache silos depending on how often the flag is specified.

[mehrdadn]

Right, that makes sense for --copt, but why --config? It seems trivial to just look for --config flags and deduplicate them? Why should it not do that?
Note that Bazel even understands that these are 'config' entries, and not arbitrary flags ("The following configs were expanded more than once: [foo]."), and it already deduplicates the warning messages too (it won't emit it 2 times if you have the flag 3 times). So it's very confusing as to why it's emitting the warning in the first place.

[ulfjack]

--config flags are expanded in-place, so it's not trivial to de-duplicate them, either. E.g.:

bazel build --config=foo --config=bar --config=foo

is not equivalent to:

bazel build --config=foo --config=bar

You also have to take into account that configs can include each other, like so:

build:foo --config=bar

[mehrdadn]

Ahh... I actually don't really grok how that works to be honest. I've seen something about "in-place expansion" in the documentation too, but it still left me confused even though I've read it several times. Would you mind giving a concrete example to show how the end result might differ?

[ulfjack]

Sure:

.bazelrc:
build:foo --copt=-Dfoo=1
build:bar --copt=-Dfoo=0

$ bazel build --config=foo --config=bar --config=foo
is equivalent to:
$ bazel build --copt=-Dfoo=1 --copt=-Dfoo=0 --copt=-Dfoo=1

For the compiler, this ends up setting foo=1.

$ bazel build --config=foo --config=bar
is equivalent to:
$ bazel build --copt=-Dfoo=1 --copt=-Dfoo=0

For the compiler, this ends up setting foo=0.

FWIW, I think this warning could be made less noisy, e.g., by filtering out non-list flags. That said, you should be able to arrange your config sections so you don't see the warning (although sometimes it may be inconvenient to do so).

[mehrdadn]

Oh wow I see. So --config= basically just forces a copy-paste of all the underlying command-line options? There's no intelligence to it at all?

Is this actually useful, or is it just an implementation quirk? Do people depend on duplication behavior like this for correctness?

[ulfjack]

The original implementation didn't inline in-place, but did something more complex that also involved de-duplicating the configs. Unfortunately, it was confusing people more than it was helping and there were numerous bug reports about it - that's why it was changed. Dumb is good.