Thanks Connor. I think we are both on the same page!
On 8/24/23 14:51, connor horman wrote:
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.
Agreed. We can have our cake and eat it to both both: (a) distinguishing
things which are already distinguished and (b) having configs follow
consistent conventions.
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.
Agreed!
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.
Agreed!
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".
Agreed! Well put --- even if we were to find a rigorous objective
definition for "Operating System" in general, encompassing a long tail
of auxiliary interfaces, it would be overly specific what what things
inspecting the output of config.sub actually care about.
(FWIW I am also fine saying there exists the "GNU Operating System", but
to me "Operating System" is always an exercise in branding, tying
together disparate components which always in principle (e.g. if we had
the source code) could be mixed-and-matched in other ways.)
I would like this very much to happen, along with the Rust project
which has it's own target defs (but similar as well).
I am glad I am not the only one!
John
