Change already transitioned labels

[plonter123]

We use with_cfg in our project.
We have a lot of configurations and we wanted to create somekind of configuration system where we would run multiple transitions on our targets, each one getting more specific.
For example we would run on our targets release transition and later we would run a platform transition, and each would choose only the relevant labels. This way we could support less configurations because the release transition would be shared by all of the release configurations.
Because each transition is more specific than the previous one we would've liked that later transitions could override previous transitions.
At the moment we tried to do this and received an error:

Error in fail: Cannot set setting '@@//...': because it has already been added to this builder

Another use case we have is a transition on a cc_binary. We have 2 transitions on cc_binary where the first one is a very long transitions which chooses a lot of configurations and the other is the same except 2 configurations, which one of them is the same as the previous one sets.

Do you think this is possible in anyway?

[plonter123]

I looked a bit in the code and it looks that to fix this would be very easy but maybe I am missing something.

At the builder.bzl file we define the set command and others, we could create another command called set_override (probably should find a better name for it) that won't check that a setting has already been set previously and could override it. Maybe also make an extend_override command.

What do you think about this solution?
When we planned our architecture we really counted on being able to override configurations in the transitions so this would be really helpful for us. Would appreciate your reply.

[fmeum]

When designing the builder API, I initially wanted builders to be immutable, which would have made it easy to share them across files. However, this would have required you to write repeated sets like this:

with_cfg(cc_binary).set(
  ...
).set(
  ...
).set(
  ...
)

That's why I went with mutable builders, which could get in your way here depending on how you are planning to use the builders and may break set_override in practice, even if we introduce it.

What do you think of a new reusable() method on builders that returns a new builder that 1) can have existing settings overridden and 2) works even if loaded from a different file and thus frozen?

If that would work for your use case, I could add that quickly. Sorry for the delayed response!

[fmeum]

I created a test case to demonstrate the problem(s): #117

[plonter123]

Just to see if I understand correctly, in order for your example to work, you would change the following line in builder.bzl:

second_builder = _first_builder

to:

second_builder = _first_builder.reusable()

Is that correct?

If so, then that would be great 👍

[fmeum]

Could you try out #117?

[plonter123]

Looks great, it worked for us.
Thank you!
🥇