"John Ericson" <l...@johnericson.me> writes: > 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.
The point is, it should not contain `windows' at all, and it should not differ from an existing triplet designating the same configuration. The objective of config development is to uniquely identify a system configuration, and nothing beyond that -- changing the set of values reported for the same configuration in the name of ``consistency'' certainly runs contrary to such an objective. > 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.) My understanding is that headers used by winegcc are provided by Winelib, not MinGW. It would be fine to distinguish this configuration from others: x86_64-pc-linux-winelib perhaps? With that said, > 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. All of the above is tangential to the subject at hand, since neither of the configurations being debated fall under the latter category. > 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. We have the means to adequately distinguish between the different Windows configurations already. Programs that want to use MSVC write *-*-winnt*, and those which need to detect MinGW write *-*-mingw*. > 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. Chances are that software written for MSVC or MinGW will not work OOTB with future Win32 toolchains, should any come into existence, making any such future proofing redundant. It is definitely no justification for introducing duplicate triplets, especially ones inconsistent with the naming scheme delinated at the start of config.sub. You are also portraying the situation from the perspective of a packager. They are not Autoconf's primary audience: users configuring programs are. Duplicate configuration names designating the same systems will aggravate the conundrum experienced by most when configuring software. Meanwhile, if config.sub normalizes the *-*-windows-* triplets as I've proposed, users can continue providing these invalid triplets, with no changes to Autoconf scripts or build files. Which is the purpose of config.sub after all. > 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. Having ported software other than Emacs to MS-Windows (and witnesses others porting even more), I cannot agree.
