cc_tool builds src for wrong platform

[anguslees]

rules_cc/cc/toolchains/tool.bzl

Line 68 in 8c94e11

cfg = "exec",

I think cc_tool(src) should be cfg=target, not cfg=exec.

Explanation: The cc_tool rule does not (itself) execute the tool as a build action (no ctx.actions.run). Presumably there will eventually be some other rule that uses the output from cc_tool as an attribute, and (importantly) also invokes the tool. That rule should consume the tool via an attribute with cfg=exec, so the tool transition can evaluate all the constraints correctly for that rule.

[pzembrod]

I don't think I quite understand the reasoning in the explanation. Why should a cc_tool() not run on the exec platform?

@matts1 fyi

[armandomontanez]

There were some aspects of the initial design that warranted putting cfg=exec there, but kind of agree with you. We should probably put cfg=exec at the cc_toolchain.tool_map attribute, and remove it from the cc_tool rule.

[matts1]

tool_map already has a transition to cfg=exec (source).

I think it should be safe to just replace exec with target.

[keith]

I think I'm getting hit by this as well but none of the matrix of options discussed here seems to fix the issue immediately. Which I imagine means there's another issue in my setup with rules_foreign_cc. But one thing I noticed that surprised me, is when I have 3 execution platforms + 3 target platforms, all with a single toolchain configured, if I cquery that toolchain this is how I see it boiled down to a specific tool:

In this example I'm on a macOS machine where the macOS + linux remote executors are registered as execution platforms, so 2 of these configurations are macOS (target vs exec) and 1 is linux, but I'm surprised to see here that there is only 1 configuration of the final llvm-ar binary, which is defined as expected with a select(). This makes it look like you will end up exec'ing the same tool regardless of exec platform, which is what ends up happening in my case, failing the build.

[matts1]

My assumption was that your situation would end up with bazel configuring a seperate set of toolchains for each of your remote execution platforms, so you'd get:

• macos exec ->macos target
• linux exec -> macos target

I'm hoping someone knowledgable about platforms can educate me more, but is it possible that since the toolchain itself says it's compatible with all execution platforms, it sees macos exec, creates a toolchain for that, then sees linux exec and sees that the toolchain supports linux and attempts to map linux to the existing toolchain instead of creating another one? I wouldn't be surprised if the original authors of the toolchain logic never considered that someone might make one toolchain for all platforms using select.

[keith]

it looks like you're right, so at least 1 way to make it work is to create 3 separate targets for all_tools that are platform specific, remove all selects from that entire tree, create 3 cc_toolchains and continue having 3 toolchain definitions with only exec_compatible_with set