Re: config.sub should normalize *-*-windows-*

[Jacob Bachmeyer]

John Ericson wrote:
> On Mon, Aug 21, 2023, at 1:17 AM, Po Lu wrote:
> > Jacob Bachmeyer <jcb62281@gmail.com <mailto:jcb62281@gmail.com>> writes:
> >
> > > No:  MinGW is Windows native "Win32" API while a future `windows-gnu'
> > > would be the GNU system's POSIX API on an NT kernel.  These are *very*
> > > different configurations; `windows-gnu' would more closely resemble
> > > Cygwin.
> >
> > This is not what the `x86_64-pc-windows-gnu' configuration presently
> > canonicalized by config.sub represents.
>
> I have offered multiple times to change it to windows-mingnu or 
> something else. Let's not be hung up on this, it is just making a 
> straw man of the broader project of making configs that are more 
> consistent.

If it describes MinGW, then it should be windows-mingw32 or 
windows-mingw64 as appropriate.  The CPU field /should/ be redundant to 
that, but x86_64 can run 32-bit code, so it would probably be a good 
idea, unless we want to canonicalize `x86_64-pc-*mingw32' to 
`i686-pc-windows-mingw'.  Should canonicalization change the CPU field 
when one CPU type has a compatibility mode for another CPU type and the 
ABI implies use of that mode?

> [...]
> > > But they already have drifted:  config tuples were originally triplets
> > > and now often feature a 4-element CPU-VENDOR-KERNEL-OS form
> >
> > Only as a result of a technical need to distinguish Linux-based GNU
> > systems from other GNU systems.  Absent that requirement, we would
> > simply call GNU/Linux systems *-*-gnu, Alpine *-*-alpine, and Android
> > *-*-android.
>
> You just said it! We have the exact same "technical need" on Windows 
> as with Linux of identifying different platforms that share the same 
> syscall interface. For the same reason we don't want people to have to 
> write *-*-gnu | *-*-alpine | *-*-android (an endlessly growing list of 
> special cases) to use e.g. the clone system call, we don't want them 
> to have to maintain a big and ever growing list of Windows variants 
> for a conditional that is just about Windows in general.

The catch here is that any package recognizing both *-gnu and 
*-windows-* would need to ensure that the match for *-gnu has priority, 
since an actual *-windows-gnu environment would be the (POSIX) GNU 
system running on an NT kernel and would /not/ have the standard 
Windows-isms that *-windows-* otherwise implies.  CygWin may have 
similar issues; I believe that it is currently treated as a unique OS 
unrelated to Windows.

Or should we define a new `windowsix' KERNEL value for POSIX 
environments on NT kernels?


-- Jacob