John Ericson wrote:
On Mon, Aug 21, 2023, at 1:17 AM, Po Lu wrote:
Jacob Bachmeyer <jcb62...@gmail.com <mailto:jcb62...@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