John Ericson writes:
> On 9/19/23 21:07, Po Lu wrote:
>
> Why not?
>
> I have on my hand several programs which use -winnt*, such as many old
> releases of Emacs. And users should be capable of replacing
> config.sub and config.guess with newer versions without ill effect.
>
> At no point has
On 9/19/23 21:07, Po Lu wrote:
Why not?
I have on my hand several programs which use -winnt*, such as many old
releases of Emacs. And users should be capable of replacing config.sub
and config.guess with newer versions without ill effect.
At no point has anyone proposed removing *-winnt-*.
"Dmitry V. Levin" writes:
> I'm inclined to remove windows-gnu from config.sub instead of renaming or
> canonicalizing it because, firstly, there is no GNU libc on windows, and,
> secondly, windows-gnu as used by LLVM means MinGW, but for that we already
> have mingw*, and we should avoid adding
Thanks Dmitry. This is an acceptable outcome to me. It is a nice middle
ground between Po Lu's and my first choice options.
John
On 9/19/23 19:58, Dmitry V. Levin wrote:
On Thu, Sep 14, 2023 at 12:55:06AM -0400, John Ericson wrote:
OK here we go:
1.
On Thu, Sep 14, 2023 at 12:55:06AM -0400, John Ericson wrote:
> OK here we go:
>
> 1. https://github.com/ericson2314/gnu-config/commit/windows-mingnu.patch
> 2. https://github.com/ericson2314/gnu-config/commit/windows-mingw.patch
> 3.
John Ericson writes:
> I used to do that, but see commit
> f0f728324021f38b0d31de399b9974535300167c : Dmitry opted to switch to
> just using Git's commit messages as the source of truth, and providing
> a make rule to generate the ChangeLog.
>
> The document you linked endorses such a choice,
I used to do that, but see commit
f0f728324021f38b0d31de399b9974535300167c : Dmitry opted to switch to
just using Git's commit messages as the source of truth, and providing a
make rule to generate the ChangeLog.
The document you linked endorses such a choice, saying
Projects that maintain
John Ericson writes:
> I had meant to just deal with windows-gnu in those 3 options,
> otherwise we have a combinatorial explosion of patches (and commit
> messages) for me to write :). Once we deal with that one we can deal
> with the others, right?
Incidentally, if you want to make it easier
I had meant to just deal with windows-gnu in those 3 options, otherwise
we have a combinatorial explosion of patches (and commit messages) for
me to write :). Once we deal with that one we can deal with the others,
right?
John
On 9/14/23 01:00, Po Lu wrote:
John Ericson writes:
OK here
John Ericson writes:
> OK here we go:
>
> 1 https://github.com/ericson2314/gnu-config/commit/windows-mingnu.patch
> 2 https://github.com/ericson2314/gnu-config/commit/windows-mingw.patch
> 3 https://github.com/ericson2314/gnu-config/commit/no-windows-gnu.patch
>
> I tried to honestly argue for
OK here we go:
1. https://github.com/ericson2314/gnu-config/commit/windows-mingnu.patch
2. https://github.com/ericson2314/gnu-config/commit/windows-mingw.patch
3. https://github.com/ericson2314/gnu-config/commit/no-windows-gnu.patch
I tried to honestly argue for each of them the best I could in
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
Quoting Po Lu (2023-08-24 21:18:13)
> People, the nature and widespread use of config.* precludes any efforts
> aimed at ``rethinking'' the tuples they accept and generate.
+1
"Dmitry V. Levin" writes:
> Hi,
>
> On Mon, Sep 11, 2023 at 10:11:39AM +0800, Po Lu wrote:
>> Where are the config maintainers? Karl Barry and company?
>> (I don't remember his e-mail nor do I have it at hand.)
>>
>> I would expect them to be actively reading this list, but instead my
>>
"Zack Weinberg" writes:
> If you could provide me a reference to your original request (e.g. URL
> in the mailing list archive) I will undertake to get it done. If I try
> to find it myself I'm afraid I will pick the wrong thing.
>
> If there is a specific git commit or commits you want
I can submit two patches (effectively amending my prior, landed patch)
with options that I think people would prefer. Will do that shortly.
On 9/11/23 17:53, Dmitry V. Levin wrote:
Hi,
On Mon, Sep 11, 2023 at 10:11:39AM +0800, Po Lu wrote:
Where are the config maintainers? Karl Barry and
Hi,
On Mon, Sep 11, 2023 at 10:11:39AM +0800, Po Lu wrote:
> Where are the config maintainers? Karl Barry and company?
> (I don't remember his e-mail nor do I have it at hand.)
>
> I would expect them to be actively reading this list, but instead my
> original request has been left twisting in
On Sun, Sep 10, 2023, at 10:11 PM, Po Lu wrote:
> Where are the config maintainers? Karl Barry and company? (I don't
> remember his e-mail nor do I have it at hand.)
Karl Berry is the Automake maintainer. I'm not sure if there *is* an
official config.* maintainer. The person most appropriately
Where are the config maintainers? Karl Barry and company?
(I don't remember his e-mail nor do I have it at hand.)
I would expect them to be actively reading this list, but instead my
original request has been left twisting in the wind.
Zack Weinberg wrote:
I haven't been following this long discussion very closely but I do have some opinions
(with my "de facto autoconf maintainer" hat on):
1. As a general rule, it is not safe to change the canonicalization (i.e. the config.sub
output) of an existing system name, *at all*;
I'd note that I don't see "rethinking target tuples" as changing how any
given name is assigned, but rather changing how they are defined and how
they are thought about.
We wouldn't break anything by changing the fourth field to mean
"Environment" rather than "Operating System", to be more
"Zack Weinberg" writes:
> I haven't been following this long discussion very closely but I do
> have some opinions (with my "de facto autoconf maintainer" hat on):
>
> 1. As a general rule, it is not safe to change the canonicalization
> (i.e. the config.sub output) of an existing system name,
I haven't been following this long discussion very closely but I do have some
opinions (with my "de facto autoconf maintainer" hat on):
1. As a general rule, it is not safe to change the canonicalization (i.e. the
config.sub output) of an existing system name, *at all*; in many cases, not
even
John Ericson wrote:
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
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)
John Ericson wrote:
On 8/27/23 23:59, Jacob Bachmeyer wrote:
[...]
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
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,
John Ericson wrote:
On 8/27/23 01:06, Jacob Bachmeyer wrote:
[...]
Ah sorry, I shouldn't have made reference to JSON at all --- what I
really was getting at is the /abstract syntax/. In particular,
rather than having an abstract syntax of "list of strings" (parsing
today's concrete syntax by
On 8/27/23 01:06, Jacob Bachmeyer wrote:
As I understand the history, Linux was the first clearly Free kernel
available. At the time, BSD still had a dark cloud hanging over it
due to its (distant) origins at AT the BSD and AT UNIX codebases
would not be legally recognized as separate until
John Ericson wrote:
On 8/24/23 23:54, Jacob Bachmeyer wrote:
John Ericson wrote:
This is why I opened with "Operating System" lacks a coherent
objective definition.
[...]
As I understand, historically, "operating systems" were proprietary
monoliths and the GNU Project originally
On 8/24/23 23:54, Jacob Bachmeyer wrote:
John Ericson wrote:
This is why I opened with "Operating System" lacks a coherent
objective definition.
[...]
As I understand, historically, "operating systems" were proprietary
monoliths and the GNU Project originally expected to produce another
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
34 matches
Mail list logo
