Po Lu wrote:
People, the nature and widespread use of config.* precludes any efforts
aimed at ``rethinking'' the tuples they accept and generate. If you
want your own format, then by all means, proceed with your own project.
But please leave config.* in peace.
I will say right now that
People, the nature and widespread use of config.* precludes any efforts
aimed at ``rethinking'' the tuples they accept and generate. If you
want your own format, then by all means, proceed with your own project.
But please leave config.* in peace.
John Ericson wrote:
This is why I opened with "Operating System" lacks a coherent
objective definition.
The more pugilistic message is to say the rest of the world doesn't
think the GNU operating system exists --- that there is simply a
choice of kernel (Linux, k*BSD, Hurd, something
Adam Joseph wrote:
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.
I argue that this is something that has
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,
This is why I opened with "Operating System" lacks a coherent objective
definition.
The more pugilistic message is to say the rest of the world doesn't
think the GNU operating system exists --- that there is simply a choice
of kernel (Linux, k*BSD, Hurd, something else...) and choices of
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
