Skip to content

Conversation

@AustinSchuh
Copy link
Contributor

There is a perfectly good cross compiler for the other Windows variant (arm64 vs x86). The only problem is that it doesn't get registered by default, so it isn't easily available. Register both of them and let toolchain selection pick the right one automatically.

There is a perfectly good cross compiler for the other Windows variant
(arm64 vs x86).  The only problem is that it doesn't get registered by
default, so it isn't easily available.  Register both of them and let
toolchain selection pick the right one automatically.

Signed-off-by: Austin Schuh <[email protected]>
exec_compatible_with = HOST_CONSTRAINTS,
target_compatible_with = [
"@platforms//cpu:armv7",
"@platforms//os:android",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this intended to be here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, that is intentional. If you look at the original BUILD.toolchains.tpl, it has that toolchain always there in addition to the configured one. This keeps that behavior. If there is someone who knows more about if that is intentional or not here, happy to make a change.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oof. This is probably some legacy jank but I'm OK with making a separate change to cull this from the toolchains. (i.e. keep it for now for consistency)

@trybka
Copy link
Collaborator

trybka commented Dec 1, 2025

My understanding of the purpose of BUILD.toolchains.tpl is to register exactly one toolchain for targeting "your host."

This would seem to be a divergence where, on Windows, we register cross-compiling toolchain(s).

How do other folks handle this? I assume most folks doing cross-compilation manually register a different set of toolchain(s)?

Do we think that Windows developers are more likely to want the auto-detected, but cross-compile capable toolchains available?

@fmeum
Copy link
Collaborator

fmeum commented Dec 1, 2025

If cross-compilation is simple to achieve and doesn't require additional tools (e.g. a large sysroot), it's generally pretty nice if the toolchain is registered automatically and users just have to set a different target platform.

exec_compatible_with = HOST_CONSTRAINTS,
target_compatible_with = [
"@platforms//cpu:armv7",
"@platforms//os:android",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oof. This is probably some legacy jank but I'm OK with making a separate change to cull this from the toolchains. (i.e. keep it for now for consistency)

@AustinSchuh
Copy link
Contributor Author

How do other folks handle this? I assume most folks doing cross-compilation manually register a different set of toolchain(s)?

Do we think that Windows developers are more likely to want the auto-detected, but cross-compile capable toolchains available?

What I see in rules_python, etc, is that the philosophy more generally is "register everything that is reasonable, and let toolchain selection pick the right one". From the user's point of view, more things just work, but bazel does a reasonable amount of extra work.

AustinSchuh added a commit to AustinSchuh/allwpilib that referenced this pull request Dec 2, 2025
Comments from bazelbuild/rules_cc#432 suggested
lower casing, let's make sure that works.

Signed-off-by: Austin Schuh <[email protected]>
@AustinSchuh AustinSchuh requested a review from hvadehra as a code owner December 2, 2025 02:56
@trybka
Copy link
Collaborator

trybka commented Dec 2, 2025

How do other folks handle this? I assume most folks doing cross-compilation manually register a different set of toolchain(s)?
Do we think that Windows developers are more likely to want the auto-detected, but cross-compile capable toolchains available?

What I see in rules_python, etc, is that the philosophy more generally is "register everything that is reasonable, and let toolchain selection pick the right one". From the user's point of view, more things just work, but bazel does a reasonable amount of extra work.

I think this is reasonable -- and clearly this PR moves towards that goal. We could probably do much more but I am OK approving this.

@trybka trybka self-requested a review December 2, 2025 18:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants