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. > 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. > `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. Perhaps that is the plan. - a
