"John Ericson" <l...@johnericson.me> writes: > 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.
So let's please remove that change, and replace it with one that canonicalizes *-*-windows-*. > 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.". GNU is an operating system. Musl-based systems are not GNU, so -musl represents a ``musl-based operating system''. > I do not think this is something to be frowned upon because "Operating > System.", after all, also lacks any rigorous objective definition. It does not, within the GNU project at least. GNU is one operating system; Android is another, as are Musl-based systems. And MS-Windows is a single operating system. > At the end of the day there is: > > 1 The syscall interface to communicate with "the outside world". (By > "kernel" we really mean syscall interface, it is possible for two > different implementations, like the actual Windows kernel, and Wine, > to support the same syscall interface.) There is already a set precedent for how such changes are treated by config*: see mips*n32, arm*eabi, et cetera. > 2 Other code linked into the same process. ABI covers the "most > important" parts of this, especially when the userland ABI is more > stable than the syscall ABI (Many BSDs, some Windows NT things, etc.) ABI differences don't constitute a new operating system. > 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. They are invalid triples. > ---- > > 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. If these configuration triplets are normalized, GNU projects (and others using config*) will automagically work when they are provided. How is that worse than forcing every program wishing to support MS-Windows to introduce express support for 2 or 3 disparate and incorrect triplets? Anyway, I plan to merge the latest config.* into Emacs soon. So speaking as someone responsible, in part, for keeping the MS-Windows port of Emacs in working order, I would like to see the change I illustrated installed ASAP.
