Optional toolchains

[ianthehat]

There are reasons to write rules where the exact toolchains used might vary depending on information available at analysis time.
The specific example here is that linking a go_binary needs a cc toolchain only if there was cgo in any of it's transitive dependencies.
At the moment to get the cc toolchain you have to say you need it in the rule, and then it is an error if one is not available, even if the go_binary rule was not really going to use it.
If we defer the error to the point of first access, then pure go builds will ask for a cc toolchain, but not get it, and go ahead to compile without error, whereas builds with cgo would complain if there was no cc toolchain but compile if there was.
There may be use cases where it would be nice to test whether the toolchain was available, but that's not strictly needed for this case.

[hlopko]

Another use case for this would be tools for various languages. E.g. rules_java use a tool called singlejar that is written in C++. This causes confusion in rules_java users: "Why do I need to have gcc installed when I'm only building Java??". We could rewrite the tool in Java, but then powerusers come and complain that the tool is too slow for them.

If we had support for optional toolchains, we could in theory use the knowledge that C++ toolchain is available to use the C++ tool, and in case it's not available, fallback to the Java tool.

</fairy_tale>

Cc @lberki, @iirina because they are interested :)

[lberki]

I think that automatically choosing a Java singlejar implementation would be actively harmful, because it would open the way towards accidental slowdowns that are hard to track down. Better be explicit than implicit.

[katre]

Placing this in the icebox since we have no plans to take on this work.

[katre]

Recent discussions (see #12897) have brought back the idea of optional toolchains. One possibility is to make all toolchains optional, and then rule implementations can provide a more-appropriate error message if they cannot continue without a toolchain of a specific type.

The main issue with this is migration: all existing uses of toolchains would need to add checks and error messages. I may take some time to consider alternatives or ways to ease this migration and bring this back to the forefront.

[philsc]

I also liked @aiuto's idea of marking all targets that don't have a toolchain as incompatible: #12419

If you then try to explicitly build an incompatible target, bazel would tell you it's incompatible because it couldn't find any toolchains.

[katre]

See https://github.com/bazelbuild/proposals/blob/main/designs/2022-01-21-optional-toolchains.md :)

[uhthomas]

Implementation tracked in #14726.

[katre]

This is now implemented and will be in the next LTS release.