Oops I had this email as draft and didn't hit send. The conversation has
moved on since a bit, but I'll send it anyways.
John
------------
On 9/6/23 19:46, Jacob Bachmeyer wrote:
The problem is that system(3) probably /does/ exist in that
configuration, but such a system is only usable as a cross-compilation
target, since building the GNU tools requires a shell.
Agree! This is exactly what I mean of "ops time" vs build time question:
if we do have system(3) we don't know what shell it will be hooked up to
in general (cross compilation is the general case).
I would say even if we are native compiling, and we find that the shell
via system(3) supports x y z, we shouldn't bake the results of a
configure-time check for that in at build time --- the installed binary
might be copied to another system with the same libc but a different
shell, and then system(3) would do something else.
I think configs are mainly useful for the host and target systems, and
thus should focus on information needed for them. Sounds like we agree
that "do we have a shell [that can do x y z]" is question that is fine
to ask of the build platform, but not really appropriate to ask of the
host or target platform. Thus, things like "presence of shell" are not
really good to include in configs.
This is all to say that telling apart OSes (as opposed to merely libcs)
seems too fraught to configs for me.
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 idea of lacking a shell was intended as an example of something
that would make a Free system /very/ different from the GNU system,
enough that it cannot be considered a GNU variant. In other words, a
Linux-based system that is clearly /not/ GNU/Linux.
Agreed it is not GNU/Linux. But I think anything that uses glibc should
use "gnu" in the config because configs have evolved to be about libc
more than OS.
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".
In this hypothetical (that needs to *stay* hypothetical) example,
"systemd" has somehow become an "OS" distinct from the GNU system.
Yes.
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!
For the "converging sequence" model, omitting the extra dashes is
important, since the number of tags prior to a "floating tag" can
vary. (I would actually suggest making "gnu" such a floating tag in
this model, with an exact definition to be obtained from a later
discussion that would need to include RMS.)
Yeah I just mean the more components we have, the more a "sparse"
representation is desirable, vs `something------another_thing`
explicitly skipping things, because the latter is so annoying (needing
to count). But that also creates ambiguities.
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.
This comes back to the "converging sequence" model issue: what to do
with the "floating tags" that are not in fixed fields?
I think it is OK if the key=value format is more expressive. In a
"design by committee" approach, the fact that it is new (no
history-induced tech debt from anyone) and fully explicit will make it
easy to avoid bikeshedding and other disagreements.
We could also think of such components as stuff whose representation in
dashed form has "yet to be standardized" --- the more expressive format
can queue up a todo list of sorts.
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.
If CPU-VENDOR-KERNEL-OS elements are always acceptable in that order
for any valid configuration, what is the point of generating the
key=value arguments instead of simply substituting into a fixed template?
Well, take MinGW for example. We cannot normalize x86_64-w64-mingw32
away --- there are some 3-component normal forms we are stuck with
because of backwards compatibility.
The new format is a chance to rethink those things without breaking
compatibility: we can always normalize to "cpu=x86_64 vendor=w64
kernel=windows libc/abi=mingw" or similar when outputting in "structured
mode".
[...]
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.
To some extent, os=gnu is a promise to the user that gets written into
command names, but I am not personally certain what exactly that
promise is. The GNU system is extremely flexible.
Right, that is where I think it is practical to yield to evolution
elsewhere and interpret "linux-gnu" as meaning "kernel=linux libc=gnu"
not "kernel=linux os=gnu".
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.
In this interpretation, *-*-windows-gnu for MinGW is /still/ blatantly
wrong, since MinGW does not use glibc.
Yes! Here's what I would say to LLVM:
> OK we will go with you in recognizing "gnu" means "abi=gnu" not
"os=gnu", but in return you deprecate "windows-gnu" because MinGW
doesn't use GNU libc.
It's IMO a nice and fair compromise: both sides share the burden/hassle
of a deprecation cycle (rather than making one side to all the work),
and we end up with much clearer definitions than we started with.
John
