|
From: | Jacob Bachmeyer |
Subject: | Re: config.sub should normalize *-*-windows-* |
Date: | Thu, 24 Aug 2023 22:54:25 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 |
Adam Joseph wrote:
Quoting Jacob Bachmeyer (2023-08-21 19:35:05)No, we are not. CPU-VENDOR-KERNEL-OS-LIBCABI, with at least one of theIf you want to redefine existing terms, please be forthright about the fact that your proposal does so.
I argue that this is something that has already happened under our collective noses (and before I had any interest in configuration tuples beyond using them with configure). The "OS" field is no longer consistent.
This usage is in conflict with the existing definition; LIBC and ABI are subfields of OS. It isn't resolving any "technical debt" -- it's sowing mass confusion. >From config.sub: # The goal of this file is to map all the various variations of a given # machine specification into a single specification in the form: # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM # or in some cases, the newer four-part form: # CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM # It is wrong to echo any other type of specification. The variable name "LIBCABI" comes from config.guess, where it is not described, but is always parsed as a refinement of the OPERATING_SYSTEM field. There is never a hyphen between OPERATING_SYSTEM and LIBCABI because they are in fact different parsings of the same string.
While I may have drawn inspiration from past work on config.guess, I used the name "LIBCABI" to reflect that it can be either a libc implementation or an ABI name; the two are usually closely related in practice.
config tuples were originally triplets and now often feature a 4-element CPU-VENDOR-KERNEL-OS formYes, we've had ~20 years to appreciate the confusion it caused, and now we know better than to do something like that again. It seems like a lot of the proposals in this thread are being evaluated not based on whether or not they are coherent, but rather on whether or not they take us a few nanometers closer to whatever happens to whatever LLVM's internal implementation details happen to be this week.
My proposals have been an effort (in my view at least) to restore coherency here, and if LLVM is using *-windows-gnu at the moment, LLVM is /wrong/. That tuple should describe a POSIX GNU environment running on a Windows system. Such an environment is theoretically possible, but does not currently exist as far as I know.
`CPU-VENDOR-linux-gnu-musl`I lack words to describe this. I suppose it could be useful if the goal were to drive config.sub into such a self-inconsistent state that everybody abandons it.
Then I need to explain it again: CPU and VENDOR are all caps because they remain variable in that pattern. Perhaps I should have written `*-*-linux-gnu-musl' there. That tuple describes a GNU system (*-gnu-*) running on a Linux kernel (*-linux-*) using Musl libc (*-musl). Do you argue that (*-gnu) should mean specifically GNU libc even though there is more to the GNU system than libc?
-- Jacob
[Prev in Thread] | Current Thread | [Next in Thread] |