rules_go provides two ways to cross-compile code:
- Users may set a target platform using
--platforms on the command line. This selects a toolchain whose "default platform" is the target platform. We declare a separate go_toolchain and toolchain for each supported platform (even though the toolchains include the same files) to make this work. This mechanism generally works well.
- Users may set
goos, goarch and other attributes on go_binary and go_test. Both rules use an aspect that creates a second graph of actions if goos, goarch and other attributes are different than the default. This mechanism the the source of a lot of problems. In particular, select expressions (used for platform-specific dependencies) do not work because select is applied before analysis.
Recent versions of Bazel support Starlark Build Configurations, which give users and Starlark rule authors much greater control over configuration transitions. We should use this functionality to remove the aspect. We may also be able to simplify toolchain declarations.
rules_go provides two ways to cross-compile code:
--platformson the command line. This selects a toolchain whose "default platform" is the target platform. We declare a separatego_toolchainandtoolchainfor each supported platform (even though the toolchains include the same files) to make this work. This mechanism generally works well.goos,goarchand other attributes ongo_binaryandgo_test. Both rules use an aspect that creates a second graph of actions ifgoos,goarchand other attributes are different than the default. This mechanism the the source of a lot of problems. In particular,selectexpressions (used for platform-specific dependencies) do not work becauseselectis applied before analysis.Recent versions of Bazel support Starlark Build Configurations, which give users and Starlark rule authors much greater control over configuration transitions. We should use this functionality to remove the aspect. We may also be able to simplify toolchain declarations.