Re: Rethinking configuration tuples

[John Ericson]

On 8/27/23 23:59, Jacob Bachmeyer wrote:

I am OK with duck-typing, but what is "all meaningful ways"? Sure, POSIX is meaningful, the exact output of uname is not, etc. but where do we draw the line?

That is a question for which I do not currently have a certain answer.  :/

Thanks, we'll keep trying to tease one out.

This is also the framework in which *-*-linux-gnu-musl makes sense for a system that uses Musl libc but is otherwise a GNU/Linux system.

Right but again where do we draw the line? For example, can one use systemd and its large entourage of intertwined software, or must one use GNU Shepherd or System V init?

In the case of *-*-linux-gnu and *-*-linux-gnu-musl, the difference is the C runtime library (GNU libc vs. Musl libc) such that shared objects linked for one ABI are not compatible with the other.  If Musl libc were exactly 100% binary compatible with GNU libc, then there would be no *-*-linux-gnu-musl platform, since it would be indistinguishable from *-*-linux-gnu.

Err I mean, is there am example of a *-*-linux-$nongnu-musl?

Agreed that if Musl was binary compatible with glibc, there would be no need to distinguish at the config level.

> The
>       choice of system service management is orthogonal to this, since
>       it has minimal impact on user programs.  (Unless systemd gets even
>       more outrageously invasive...)

Agreed, just wanted to double check.

> Except configure usually does not need a "fully disambiguated"
>       form---the canonical form produced by config.sub is fine, since
>       configure is usually matching against the full tuple using shell
>       case patterns.  The flat list with a defined order is optimal for
>       this strategy, since it allows to easily check for the presence of
>       any tag or combination of tags.

Shell case patterns can be a bit of a footgun. For example, a common mistake is doing * instead of *-*. I would rather case on disambiguated variables. Indeed, AC_CANONICAL_HOST computes host_cpu, host_vendor, and host_os for precisely that purpose. If config.sub could split out the disambiguated form, those variables could be defined more simply and robustly.

Note that config.sub is itself a shell script, and handling JSON in shell is a giant pain.  The most we could reasonably do is what config.sub already does:  determine each component as a separate variable and then output that by substituting text into a template.

Yes I agree config.sub in its current form (must be highly portable across different Bourne-shell derivatives) has no hope of parsing JSON. It could output it or it could also output your ${key}=${value}\n format, and it could also consume your format. Your format is ideal for it!

Adding a prefix to each key in the key=value format is trivial and would further help shell scripts that want to "parse by eval" but configure itself tests predicates rather than caring exactly what part of the configuration tuple means what.  Put another way, configure is usually looking for a yes/no answer, so a pre-parsed form is less useful than a single string that can be used for pattern matches.

I agree testing is more robust, but for better or worse I still do see scripts using those host_* variables mentioned above. (Testing is possible but requires more care to get right for cross-compilation, for one.)

> There is no reasonable way to feed the key=value format into
>       config.sub: configuration tuples are hyphen-delimited lists.

I think there is. The overall algorithm is roughly "(a) decide which component is which, (b) sanitize and normalize components decision to that decision". We would skip step (a) and go straight to step (b) in order to do this.

This indicates part of the value of doing this: rather than just "system testing" the entirety of config.sub, we would now have something closer to a "unit test" of part of it in isolation.

FWIW, this is similar to a rearranging the code to a support a mode where non-normal-form configs are rejected instead of normalized.

> Producing
>       key=value format using config.sub's knowledge of valid tuples
>       might be reasonable for other systems to use instead of
>       needing their own parsers.

Yes it is definitely necessary for that, and that is a good use-case for sure.

Thank you; as I mentioned above, the goal is to best support heterogeneous multi-arch systems, but recognizing a tension here.  For configure, the configuration tuple should not contain information that can be determined by testing, but for storing multiple binary sets, ABIs do need to be part of the name, even if they can be determined by configure tests.

Agreed configure tests are better for the "long tail" of other attributes. (IMO if we were to define "operating system", it would be something like the "limit" of all configure checks.)

But a big part of my "kernel-libc" thinking (and I think also Connor's) is that kernel + libc mostly determines on OS for toolchain purposes. E.g. even if there exists both GNU-like and non-GNU linux-musl systems, they can share the same prefixed binaries, so there is no need to distinguish them at the config level.

Do you have a counter-example where a sameKernel-OS_0-sameLibc and a sameKernel-OS_1-sameLibc would need different prefixed binaries, and thus the inclusion of OS in addition to kernel and libc is necessary to avoid binary name collisions?

I am not entirely certain why, but I know that there is some reason we call the common GNU/Linux systems *-*-linux-gnu instead of *-*-linux.

To be honest, I think this is basically the "call it GNU/Linux not Linux" controversy --- i.e. at the time it was done for social not technical reasons. I don't mind, since now that we have multiple libcs there is a technical reason to distinguish. But this circles back to my hunch that Kernel (syscall interface) + libc (ABI) determines OS uniquely enough for config.sub's purposes.

I called the fifth field "LIBCABI" because it can be a libc name or an ABI name; in practice the two are usually closely related.  Some existing tuples place a libc name in that slot, while others use a more generic ABI or file format name, such as "elf" in your example.  For it to be a source of confusion, there would need to be a libc that supports multiple ABIs, and you would simply use the ABI names in that case.

Perhaps you know of examples of existing ones out in the wild that I am not aware of that need to include kernel, OS, and libc? Do share if you do!

The major example that immediately comes to mind would be a GNU/Linux distribution using Musl libc.  But that comes back to why *-*-linux-gnu exists in the first place...

Erm I mean not an extant system that would use such a config under your system, but an extant config (not necessarily a GNU one, could be an LLVM, Rust, or something else one) for such a system. In other words, I am asking whether there was a case where someone else evidently decided that kernel+libc was not enough info and OS was also needed to further disambiguate.

John