Re: Rethinking configuration tuples

2023-09-10 Thread Po Lu
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.

Re: Rethinking configuration tuples

2023-09-10 Thread Jacob Bachmeyer
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*; in

Re: Rethinking configuration tuples

2023-09-10 Thread connor horman
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 well-de

Re: Rethinking configuration tuples

2023-09-10 Thread Po Lu
"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, *a

Re: Rethinking configuration tuples

2023-09-10 Thread Zack Weinberg
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