Po Lu wrote:
"John Ericson" <l...@johnericson.me> writes:
[...]
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.
At this time, yes. However, the GNU utilities are designed to be fairly
portable and the NT kernel was designed to support multiple ABIs, so a
hypothetical port of GNU to run under MS-Windows is within the realm of
possibility. (In fact, the underlying architecture of NT should have
all of the primitives needed to support HURD or a closely related
system.) It is more likely that this would be implemented on ReactOS
(which aims for ABI compatibility with NT 5.1, is a stable target, and
is Free) first, but a hypothetical `x86_64-pc-windows-gnu' (or perhaps
`x86_64-pc-reactos-gnu') config tuple *is* a future possibility.
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.
And what would we canonicalize `x86_64-pc-windows-gnu' to, other than
itself, currently?
It appears that config tuples may be drifting towards a 5-element
CPU-VENDOR-KERNEL-OS-LIBCABI form, with each of the last three elements
potentially optional, which makes any real tuple ambiguous, except that
the valid strings for KERNEL, OS, and LIBCABI are from distinct sets.
-- Jacob
