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 the
If 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 form
Yes, 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
