can you rebase? i think the argument that the default toolchain does this is enough for us to do it here too, but what's the use case for this vs passing --copt somewhere? i feel like most folks find that easier to throw in their .bazelrc

Happy to rebase.

I started with --copt and found its limits, hence this change.

I'm doing a multi-platform build. I'm both compiling for a mac (universal binary), and building for an embedded linux platform. I'm using transitions to generate a maven artifact with all the architectures and operating system binaries in it at. --copt and friends is global, not per platform, and one set of flags doesn't work for both Linux and Mac. This means either I need to also start baking the value of --copt into the transition (I didn't confirm this is possible since it smelled like an anti-pattern), or move the different flags to the toolchain directly and let toolchain selection handle it for me. I chose the second since that feels like it fits Bazel's model better.

I will say, it took me longer than I would like to admit to discover that the toolchain in rules_cc doesn't get used and this is the real one. I was reading that one and trying to figure out why the environmental variables didn't work.

But if both tool chains read this doesn't that mean you get the same behavior as a global copt?

Correct. In my case, I am providing a second toolchain which is configured differently. I have a working review I can share with this applied as a patch.

I think the ideal solution would be to be able to configure the toolchain from the workspace/module.bazel file. I think that is a larger change though, and more work to coordinate the API to match across all the platforms.

i think this is fine, likely the real change will be once we can use rules based toolchains here we'll expect users to add features manually for this kinda thing instead

Oh, 100%, rule based toolchains would be a lot better here. One day...