There is nothing inconsistent about any of these examples. Universally, when talking about compiling a compiler, “host” refers to “the system where the built compiler will run”, and “build” refers to “the system where the compiler will be compiled”.
To redefine “build” to mean “the system where the Swift compiler would run” would be an incredibly confusing redefinition of existing terms.
I think you are glossing over an inherent complexity of building a toolchain than anyone working on SDK content must be aware of. The Canadian cross is the default situation for most Swift developers who will use this feature: they develop their SDK content on either x86 or Apple Silicon, build it for both, and then their clients use that SDK content to target iOS.
Please have a look at the links to documentation of existing tools I've provided. They explicitly say they are not talking about compiling a compiler. What they're saying is that "build" and "host" are used when cross-compiling any software, "target" comes into play only when compiling a compiler. Here's Meson documentation again:
build machine is the computer that is doing the actual compiling.
host machine is the machine on which the compiled binary will run.
target machine is the machine on which the compiled binary's output will run, only meaningful if the program produces machine-specific output.
Both automake and autoconf agree with these definitions, as they're used for compiling other software in general, not just GCC.
Not confusing at all if you've previously used automake and autoconf, as a big proportion of software built for Linux does, and SE-0387 is primarily meant to make cross-compilation to Linux easier.
Note that I personally am not proposing "build" to always mean "the system where the Swift compiler would run", I'm only quoting how other tools define it that way. I'd prefer a new term to avoid any potential confusion, if only because CMake and autotools couldn't agree with each other about definitions of these terms.
The relationship between build, host, and target have been cleaned up: the chain of default is now simply: target defaults to host, host to build, and build to the result of config.guess.
So it’s inaccurate to say there’s no mention of target. It’s implied to be inferred, whether or not it’s used.
But you can build a cross-compiler without specifying --target because it’s inferred from --host.
This statement goes to my point: when you are using a build system to build part of a toolchain, the recursion makes it complicated. If you’re not building a cross-compiling compiler, it suffices for “target” to default to “host”. But most people who use this feature will be building part of a cross-compiling toolchain, Canadian or otherwise. They need to be able to understand each of “build”, “host”, and “target”, even if they don’t need to specify all three 99% of the time.
which is true. There is a passing mention of "target", but not a single mention of the --target option, because it's irrelevant in the context of basic cross-compilation with autotools.
Exactly. You can also build any other software without passing --target to autotools, since in their nomenclature --target is a special case relevant only for Canadian Cross, and for all other cases they refer to "build" and "host" triples.
Even though I disagree with this, I don't see how it's relevant to the discussion.
What percentage of people need to specify all three is not something I'm willing to debate. It's what terms people should use for two out of these three for basic cross-compilation that interests me. If everyone agreed on what two of those terms are and what they "universally mean", we wouldn't have this second review in the first place.
You can’t make that decision in good faith without acknowledging that all three environments are relevant to building toolchain content. This is the complexity and mental burden one takes on when deciding to become a Swift SDK content provider.
Since all build systems that have explicit support for specifying all three environments use the same terms for each, I strongly think Swift should follow suit. Notably, CMake does not have explicit support for specifying all three environments. This causes dissonance when using CMake to build LLVM. That dissonance seems to be the source of this debate, and to me it seems to be squarely the fault of the CMake developers.