Rethink how cross-compiling works, including the terminology

[infinity0]

The current config.toml.example in rust says:

# In addition to the build triple, other triples to produce full compiler
# toolchains for. Each of these triples will be bootstrapped from the build
# triple and then will continue to bootstrap themselves. This platform must
# currently be able to run all of the triples provided here.
#host = ["x86_64-unknown-linux-gnu"]   # defaults to just the build triple

# In addition to all host triples, other triples to produce the standard library
# for. Each host triple will be used to produce a copy of the standard library
# for each target triple.
#target = ["x86_64-unknown-linux-gnu"] # defaults to just the build triple

Note that the terminology here is confusing. "build" in the cross-compiling context actually refers to the "host" platform in a normal compilation context, and "host" in the cross-compiling context actually refers to the "target" platform in a normal context. "target" in the cross-compiling context does not have an analogue in the normal context, since normally one is not compiling a compiler. If you are confused, more suitable names might be "host", "target-compiler" and "target-libstd". In fact it may be better to rename the config.toml keys to these ones. The older more confusing terminology comes from GCC I believe, and perhaps they got it from even older terminology.

In "host" where it says "This platform must currently be able to run all of the triples provided here." - this is (1) ostensibly not true, we have been cross-compiling in Debian arbitrary platforms A to arbitrary platforms B for a few years now by setting build = A, host = [B], target = [B] and (2) not desired, since you want to be able to arbitrarily cross-compile from any platform A to any platform B.

TL;DR: I'm not sure the original intention behind that statement, but it's not true today, not desired, and at least the documentation should be fixed.

In "target" where it says "Each host triple will be used to produce a copy of the standard library for each target triple" is unfortunately true, for example in Debian we have found cross-compiling to break when setting build = A, host = [B], target = [B, wasm32], and then the bootstrap tries to compile libstd:wasm32 using rustc:B which platform A can't run. (For some reason, if target is set to only [B], the bootstrap does not try to compile libstd:B using rustc:B, as noted also in the previous paragraph.)

I'm also unsure of the original intention behind this behaviour, I don't see why it's necessary or desirable to compile all target platforms (i.e. all libstds) using all of the host platforms (i.e. toolchains) that you're building, since some of these toolchains might not be executable by the build platform.

I would suggest this be fixed to "the build platform will be used to produce a copy of the standard library for each target triple". I tried doing this, but couldn't figure out how to make this work. In src/bootstrap/builder.rs in maybe_run I tried changing the "for host in hosts, for target in targets" double-loop into two single loops each with host: set to builder.build.build and target: set to either host or target, but then other stuff broke.

It doesn't help that the terms "host" and "target" are overloaded so confusingly too.

[Mark-Simulacrum]

In "host" where it says "This platform must currently be able to run all of the triples provided here." - this is (1) ostensibly not true, we have been cross-compiling in Debian arbitrary platforms A to arbitrary platforms B for a few years now by setting build = A, host = [B], target = [B] and (2) not desired, since you want to be able to arbitrarily cross-compile from any platform A to any platform B.

TL;DR: I'm not sure the original intention behind that statement, but it's not true today, not desired, and at least the documentation should be fixed.

I think this is true if you try to run tests, right? Or at least (I believe I wrote that statement) that's why I wrote it

I agree that figuring out better names here (perhaps the ones you suggest) and then utilizing those to change exactly what we compile is likely a good idea. I'm not sure if I personally have the time to do so, but I think at least the literal name change may not be too hard for someone to implement (mostly a matter of letting the compiler guide you, hopefully) and that would make further steps easier.

cc @alexcrichton as well

[alexcrichton]

I don't really have many opinions here so long as things keep working. This isn't really a particularly high priority for me personally so I won't be that available for in-depth discussions about this terminology.

[infinity0]

I think this is true if you try to run tests, right? Or at least (I believe I wrote that statement) that's why I wrote it

Yes, you're right but I think that's the only case. In Debian (and I'd expect elsewhere) when we cross-compile we don't run the tests because they are expected not to be runnable. I'll update the documentation to reflect this.

This isn't really a particularly high priority for me personally so I won't be that available for in-depth discussions about this terminology.

Thanks for the comments, I understand if this is not a high priority for rust. I might need some help understanding the current rustbuild code however. I still was not able to figure out exactly why setting build = A, host = [B], target = [B] does not result in rustbuild trying to build libstd:B using rustc:B, but only using rustc:A. Presumably because libstd:B already exists (after having been built by rustc:A), but I was not able to identify the exact point in the code which encodes this logic.

There is also a regression regarding cross-compile install (#42320) which I have a fix for, but I have no idea why/how it works and the fix was not needed previously.

[infinity0]

Although I do note that one can currently do a lot of different things now already, by ignoring config.toml and passing --host and --target explicitly to ./x.py, which seems to work better / more predictably. So that's what I'm doing for now in the Debian cross-compiling builds.

[Mark-Simulacrum]

FWIW, I think that tracking down such particular in rustbuild (i.e., why is this host being used to build this std) is not something that anyone can be of particular help with; it's unfortunately true today that we don't have anyone (to my knowledge) who has all of that in cache sufficiently to be able to dig in without doing the investigation, and I also don't have time unfortunately to do that legwork.

With regards to why things are the way they are I'm afraid I also can't be of much help -- IIRC, that's just the way things were when I started working on bootstrap and we kept things the same since then. It's likely that changes there could be done, and perhaps you would be a good person to do them given insight into the packaging side of things. We'll want to also be careful that what we test/dist on our CI here, but mostly just relying on a few smoke tests and such is hopefully enough (and we do have some partial tests in bootstrap, though they have nowhere near 100% coverage).