On 8/30/23 22:24, Jacob Bachmeyer wrote:
John Ericson wrote:
Err I mean, is there am example of a *-*-linux-$nongnu-musl?
I would expect that to name an embedded environment using Musl libc
and the Linux kernel, but that is not a full system. (Example: may
not even have a shell at all)
I suppose except for the system() function in libc, I would consider
this a distinction not needed for configs. The choice of what other
programs to run (be they init or shell) feels to me not like a
build-time / development configuration decision, but a a runtime / ops
configuration decision. They aren't "viral" decisions in the way that
the choice of libc is (since all shared objects that may be combined
together need to agree on their deps, most notably libc).
Maybe this could go in the config per the "arbitrary many components,
finer distinctions to the right" "converging sequence" approach, but
then I would want this further to the right, e.g.
aarch64-unknown-musl-noshell not aarch64-unknown-noshell-musl.
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.
Of course, if systemd *does* get sufficiently outrageously invasive,
we might need a *-*-linux-systemd-glibc tuple... (Since systemd
gleefully makes extensive use of Linux-kernel-specific features, it
cannot possibly be a standard on the GNU system, which supports
multiple Free kernels.)
Yes I agree systemd probably can't be "bonafide GNU OS", but I take the
opposite conclusion that this is evidence for the "gnu" for glibc is
more important than the "gnu" for "true GNU OS".
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 *-*.
If the allowed pattern elements are sufficiently unambiguous, there is
no mistake, since `*' matches text including `-'. In fact, when
testing n "is tag FOO present?" predicate `*-foo-* | *-foo' would be
correct. (I assume that a CPU type will remain required and will
remain first in the list.)
Sorry I meant as part of a larger pattern. With things like *-stuff-* vs
*-*-stuff-*-*, the extra dashes are needed to make sure "stuff" matches
the right component, and even then it only works if one knows the exact
number of components (which can be accomplished by *-*... and the
ordering of patterns). It is quite subtle!
Allow the hypothetical --parse option to accept a PREFIX argument and
you are pretty much there:
$ ./config.sub --parse=host x86_64-linux-gnu
host=x86_64-pc-linux-gnu
host_cpu=x86_64
host_vendor=pc
host_kernel=linux
host_os=gnu
$
That form should be both easily parsed by other tools and suitable for
`eval` in shell scripts.
Yup! We're in agreement.
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.)
In this case the test is `case $host in ... esac`.
I would say it is better to case on (combinations of `host_*` variables
than `$host`, because then knows exactly what components are being cased
upon; there is no ambiguity. I think one should basically only use
`host` as a block-box identifier (e.g. prefixing binaries) and and other
time one would like to use `host` they should use the `host_*` variables
instead.
The problem is still getting it /into/ config.sub: config.sub expects
a single command-line argument, while pre-parsed form spans a few lines.
I don't think that is so hard. config.sub accepts --gnu-long-args
already )without confusing them as configs) so we can simply do
something like
./config.sub --pre-categorized cpu=x86_64 vendor=pc kernel=linux os=gnu
and then there is no confusing the two forms of input.
[...]
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.
That is possible, but still a valid reason for the GNU Project to stay
with that angle.
Yeah I have no problem with the term GNU/Linux, I just don't think "OS"
is useful for config.sub. "Linux + GNU libc" for config.sub; "GNU/Linux"
for humans/prose.
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.
I do not know of any off the top of my head.
OK. For the record, I wouldn't focus on this "OS-libc" stuff so much,
except I suspect it would get in the way of the sort of grand
reconciliation between us, LLVM, Rust, etc. that needs to happen. If the
"OS is actually libc" way it's ended up elsewhere is acceptable to GNU
Config, as I hope it can be, and how downstream often uses GNU Config in
practice, that gets us much closer to consensus.
John
