|
From: | John Ericson |
Subject: | Re: config.sub should normalize *-*-windows-* |
Date: | Fri, 18 Aug 2023 13:42:29 -0400 |
User-agent: | Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440 |
On 8/18/23 07:42, Zack Weinberg wrote:
On Thu, Aug 17, 2023, at 8:34 PM, Po Lu wrote: ...Given that the MinGW ABI does not constitute the GNU operating system executing on the MS-Windows kernel, and MSVC is not an operating system, such blunders should be ignored, or at least normalized...
In fairness I just recently submitted the patches added them, so absent a clear notion of GNU config releases I think a grace period where we can reconsider recently added changes is acceptable.
Even more important than this is the principle that config.sub canonical names are *never* changed, even if they are wrong according to some external standard.
That said, I don't think we should so normalize them. I took them
from LLVM, which has supported them for years and normalized in
the *other* direction (i.e. to these), and Rust which follows
LLVM's lead. I knew we couldn't change the old ones to normalize
to the new ones, so I thought a fair middle ground was that
neither would normalize to the other.
For the record LLVM, Rust, and even sometimes GNU config don't
treat *-*-foo-bar as *-*-$kernel-$os, but rather *-*-$kernel-$abi. Where ABI is a
sort of catch-all residual. This is why e.g. riscv-unknown-linux-musl is accepted ---
no one would think the Musl libc is an operating system! Rather
"gnu" is interpreted to be mean "glibc, libstdcxx++, etc.".
I do not think this is something to be frowned upon because
"Operating System.", after all, also lacks any rigorous objective definition.
At the end of the day there is:
And even ignoring all that, the *windows*-* convention makes
clear that these are variations of extra stuff atop on Windows.
In many instances, it doesn't matter which one of them is in use. Using the new triples makes it
easier for that agnostic code to roll with the punches.
----
My intention in adding these to GNU config was to then rework our
Windows cross compilation in Nixpkgs to use them, which would mean
likewise submitting patches to GCC and other things to accept them
too. Normalizing them away would prevent me from doing all these
other yak shaves, and trying to get the various flavors of Windows
cross to work more consistently, because everything downstream
from config.sub invocations would work the same way as before. IMO
that would basically defeat the purpose of accepting them at all
in GNU config --- better to reject that do a normalization that
may not be desired.
Cheers,
John
P.S. CCing Saleem Abdulrasool who originally added them to LLVM in https://reviews.llvm.org/D2947, and who
has continued to work on LLVM-land Windows support, e.g. for Swift. (I
imagine Swift, like Rust, also uses the *windows*-* ones.) Perhaps
he may have some additional insight to add.
[Prev in Thread] | Current Thread | [Next in Thread] |