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

[John Ericson]

On Mon, Aug 21, 2023, at 1:17 AM, Po Lu wrote:

Jacob Bachmeyer <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.

> I say it would be more appropriate to accept `x86_64-pc-mingw64' as a

> short form for `x86_64-pc-windows-mingw64', since Wine could enable a

> `x86_64-pc-linux-mingw64' platform to exist.  (Wine's goal is that

> that platform should be indistinguishable from

> `x86_64-pc-windows-mingw64', but it is certainly a distinct

> configuration from the user's perspective.)

Wine is a compatibility layer that emulates the MS-Windows kernel.  It

is not config's role to report the intricacies of the operating system

implementation, only details that affect user programs running under

that operating system.

You have misunderstood Jacob's point, which is that the MinGW interface has multiple implementations, namely top Windows itself and via Wine. Indeed see https://manpages.ubuntu.com/manpages/kinetic/man1/winegcc-development.1.html, this already exists via winelib and GCC. (MinGW is basically "modify MS headers so they work with GCC", and thus the same modifications are needed whether we are going to run on windows or on some Unix with winelib.)

We never want to distinguish implementations that present the exact same interface (indeed, that defeats the point of re-implementing the same interface, going down this road yields a cat-and-mouse of endless lies like browser user-agent strings), but we do want to distinguish different interfaces.

> 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.

As a Nixpkgs developer, my goal is to see all the free software in the world packaged in a single way which will run (or can be cross-compiled to everywhere). This is very ambitious, and the only way it will work is if it is easy for upstream software to be portable. And it way to make it easy to be portable supporting all the variations is if we clean up foot-guns like this where upstream software has to maintain every-growing disjunctions rather than future-proof wildcards.

Sure, this sort of tech debt OCDing I am doing freely admit seems over kill for just one package (emacs) and one windows platform (MinGW), but please believe me when I say when considering all the variations and all the package it *does* become something worth practically caring about.

John