--platforms flag is not respected

[juanzolotoochin]

To repro, on a Linux x86 machine:

$ git clone https://github.com/bazel-contrib/rules_multitool.git
$ cd rules_multitool/examples/module

# add a mac os platform
$ cat << EOF >> BUILD.bazel
platform(
    name = "macos_arm_platform",
    constraint_values = ["@platforms//cpu:arm64", "@platforms//os:osx"],
)
EOF

# build a tool targeting the new platform:
$ bazel build @multitool//tools/aws --platforms=//:macos_arm_platform

Target @@rules_multitool~~multitool~multitool//tools/aws:aws up-to-date:
  bazel-bin/external/rules_multitool~~multitool~multitool/tools/aws/aws

# Check the output file
$ file -L bazel-bin/external/rules_multitool~~multitool~multitool/tools/aws/aws

bazel-bin/external/rules_multitool~~multitool~multitool/tools/aws/aws: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.9, BuildID[sha1]=57d72cf729cd32a0e508deaf2ac7ffd272dd724c, stripped

Expected behavior: Output should be a MacOS ARM64 file.
Actual behavior: Output is a Linux x86 file.

Note: I haven't been able to reproduce this from a MacOS host.

[juanzolotoochin]

This is the fix that Claude suggested

The root cause is that Bazel was selecting toolchains based on exec_compatible_with (the host machine running the build) instead of target_compatible_with (the platform being built for), causing cross-compilation with --platforms to select the wrong binary.

diff --git a/multitool/private/hub_repo_template/toolchain_info.bzl.template b/multitool/private/hub_repo_template/toolchain_info.bzl.template
index f5dd020..9b7b39c 100644
--- a/multitool/private/hub_repo_template/toolchain_info.bzl.template
+++ b/multitool/private/hub_repo_template/toolchain_info.bzl.template
@@ -35,16 +35,6 @@ def declare_toolchain(name, os, cpu, toolchain_type):
         ext = ext,
     )

-    native.toolchain(
-        name = "{name}_{os}_{cpu}_toolchain_exec".format(name=name, os=os, cpu=cpu),
-        toolchain = ":{name}_{os}_{cpu}_toolchain_info".format(name=name, os=os, cpu=cpu),
-        toolchain_type = toolchain_type,
-        exec_compatible_with = [
-            "@platforms//cpu:{cpu}".format(cpu=cpu),
-            "@platforms//os:{os}".format(os=os),
-        ],
-    )
-
     native.toolchain(
         name = "{name}_{os}_{cpu}_toolchain_target".format(name=name, os=os, cpu=cpu),
         toolchain = ":{name}_{os}_{cpu}_toolchain_info".format(name=name, os=os, cpu=cpu),

This fixes my use case. But I'm not familiar with this codebase and I'm not sure if it breaks anything. Claude did run the tests that it found on the repo though.

[markelliot]

ah, so yeah that's a toolchain resolution issue, and for whatever reason your build is not resolving the correct toolchain. I think you can force this correctly with a transition on your target

[juanzolotoochin]

The transition doesn't work, it has the exact same behavior as the --platforms flag.

[markelliot]

I think it's beyond my understanding of toolchain resolution, but these two toolchains are, as far as I'm aware, correctly constrained (one by exec, the other by target), and I would've expected a build constrained by platforms to select the target toolchain by the constraint. @alexeagle any ideas here?

[hunshcn]

Hi everyone, regarding the discussions in #104 and #124:

I’ve been thinking about the conflict between target_compatible_with and cross-compilation requirements. It seems we are hitting a wall because the binary targets are being evaluated against the Target Platform even when used as build tools.

What if we fully embrace the Toolchain Resolution model? We could:

• Keep target_compatible_with on the raw binaries to reflect their native platform.
• Use exec_compatible_with on the toolchain() declarations to gate their usage.

This decouples the "tool's existence" from the "build's target". When a rule requests a multitool via toolchain_type, Bazel will correctly match the binary to the Execution Platform, regardless of whether we are cross-compiling for Android, iOS, or WebAssembly.

Has this "Toolchain-first" approach been considered as the default macro output for rules_multitool?

[hunshcn]

@markelliot @alexeagle any ideas?