This is why I opened with "Operating System" lacks a coherent objective
definition.
The more pugilistic message is to say the rest of the world doesn't
think the GNU operating system exists --- that there is simply a choice
of kernel (Linux, k*BSD, Hurd, something else...) and choices of
libraries and system components on top of that, and many combinations
are possible. The rest of the world might say this in a mean way, but I
say it is actually a /good/ thing --- software freedom means one /can/
choose my components à la carte, and only a lack of software freedom
results in a kernel and mass of libraries outside one's control blurring
together into a scary "take it or leave it" monolith we call an
operating system.
On 8/24/23 08:51, 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.
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.
I'll add that all linux-* configs in config.guess use LIBC/LIBCABI. I
take this as further evidence that distinguishing OSes atop Linux is
useless. Per the above, I think this is good!
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.
Adam are you saying you prefer the state of 3-component configs?
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.
I care about coherence, the reason I like to see what LLVM does that
working from a parsed representation forces the software to be much more
honest. Since GNU config doesn't reveal its categories but just spits
out another opaque string, there is no external pressure for its
categorization to be any good. LLVM, on the other hand, dispenses with
strings entirely and just uses the enums, so it is forced to make sure
those enums make sense and work for the branching the program has to do.
LLVM parsing of configs is ad-hoc Postel's law stuff like everyone else,
but its internal representation is actually quite stable. Parsing is the
ugly nasty part that gets to the pristine clear ontology on the other side.
Ultimately I would like to convene everyone to commit to an agreed upon
internal representation too. E.g. clang and GNU config could both spit
out some JSON that is unambiguous and should match. I think that would
alleviate a lot of Adam's concerns about "following LLVM". But I don't
think it is possible to convene the working group needed to standardize
such a format yet, because there is little trust between parties. Moving
us a "a few nanometers closer" on each side demonstrates that there is
willingness to compromise.
-----------
Concretely, I think these are pretty clear configs:
CPU-VENDOR-windows-mingnu # MinGW, MS C + GNU C++ and other GNU-ish
things, TODO distinguish between MSVCRT and UCRT
CPU-VENDOR-windows-cygnus # Cygwin
CPU-VENDOR-windows-msys # MSYS2, a lot like Cygwin
CPU-VENDOR-windows-msvc # MS C + MS C++
CPU-VENDOR-linux-gnu # gnu libc
CPU-VENDOR-linux-musl # musl libc
CPU-VENDOR-linux-android # bionic libc
I know Po Lu doesn't like them, because they overlap with existing ones.
But what about you two, Adam and Jacob? I am trying to compromise
between what various things do already, and and also correct things like
windows-gnu (even if there is no such thing as the GNU operating system
(only multiple GNU Hurd-supporting distros), I agree that MinGW is
clearly not a complete enough of set of GNU software to earn the right
to drop the "minimal" part).
If we can accept these, I think I will have no problem getting LLVM to
accept windows-mingnu, and perhaps even warn/deprecate windows-gnu.
After that, I think we are close enough to convene a working group for a
JSON/whatever explicit standard. And that would be amazing.
-----------------
John
