"John Ericson" <l...@johnericson.me> writes: > If Musl, GNU Libc, and Android are all different operating systems, > why are MSVCRT, MinGW, and Cygwin not different operating systems?
Musl is not an operating system, but Musl-based systems are distinct from GNU and Android systems, in that they share nothing in common except for the Linux kernel. These considerations are GNU project policy, see: https://www.gnu.org/gnu/why-gnu-linux.en.html In contrast, MinGW and MSVC are merely different compilers for the same OS, using a different ABI, but the same system libraries and services. A program will run on any MS-Windows system irrespective of whether it was compiled with MSVC or MinGW. And config.* already regards Cygwin as a separate operating system. > The simplest reading of history that doesn't require any contortions > is that MinGW and Cygwin predated configs with more than 3 components, > but Android did not. That's an inaccurate portrayal of history, at best. See below. > Had those Windows-based platforms been introduced later, something > like the configs that Saleem added to LLVM would have been used from > the get go --- grouping the Windows-based platforms and grouping the > Linux-based platforms are both advantageous ways of categorizing > things, and advantageous for the same reasons. We are trying to develop the GNU operating system, and it is in our interest to convey the distinction between GNU systems employing the Linux kernel, and other operating systems that are - by happenstance - built on top of the same kernel. OTOH, MinGW does not provide an operating system founded upon the Windows kernel, so it is incorrect to apply the: machine-vendor-kernel-OS quadruplet scheme to it. To rub salt into the wound, the GNU operating system does NOT run under a MS-Windows kernel. So ``windows-gnu'' is not just conjecture, it is also a misnomer. > As I said in the other email, I am not forcing anyone to do anything. You are, as users will soon begin to provide invalid triplets such as `x86_64-pc-windows-gnu' to their configuration files. And instead of canonicalizing them, the express purpose of config.sub, they are reproduced verbatim, much to the detriment of configure scripts and to the chagrin of package maintainers. > You can take the latest version and do nothing else. Anyone that uses > *-windows-gnu will have their build fail, just as it fails > today. There is no problem. Users will start expecting configure to grok such configurations. We will start receiving bug reports, for the simple reason that the present config.* cabal failed, in this case, to excercise the elementary degree of circumspection and good judgement that should be applied when maintaining a program underpinning thousands of important GNU (and other) projects.
