It seems to me reading this thread that we've come into two conflicting realities: * There exists targets that need to be distinguished, and * They are not distinct in any component that config.sub has, therefore they cannot and should not be distinguished.
mingw and msvc both use the NT kernel, and the windows operating system. So it seems to me that windows, the OS, is the correct way to describe them. According to the discussions on this thread, they should thusly both canonicalize to the same target. And yet, not only is there desire to separate these targets, they already are. LLVM (as well as my own target parsing tool) refer to the last two components as "sys" with two subcomponents (of which at least one exists), being os and env. IMO, this seems a far more coherent definition that satisfies the requirements, and even more correctly matches targets that already exist. musl is another extreme example: There is no musl OS. The last component being musl refers to the use of the musl libc. The resulting binary can then be used on either a GNU system or a non-GNU linux system like alpine, void, or iglunix. Thus musl cannot be regarded as an "OPERATING_SYSTEM" but rather an an environment. Even on linux-gnu the definition is murky at best. While I won't dispute the existence of a GNU operating system running atop the linux kernel, in many cases, the actual linux-gnu tag merely refers to glibc. Few things using targets nowadays actually cares about the rest of the tools, and when they do care that they exist (on --host or even --target), they typically don't care that they're provided by GNU, and even may not care that they match the interface of the tool provided by GNU. Only on --build are the tools really cared about, and I don't see many things matching the build tuple or even canonicalizing it. If we thus define an "Operating System" as "kernel+libc+tools atop that" it becomes clear to me that few things written nowadays care about the "GNU Operating System" and only really care about the "GNU Environment". On Thu, Aug 24, 2023 at 12:22 John Ericson <l...@johnericson.me> wrote: > 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. > I would like this very much to happen, along with the Rust project which has it's own target defs (but similar as well). > > ----------------- > > John >
