config-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rethinking configuration tuples


From: Po Lu
Subject: Re: Rethinking configuration tuples
Date: Mon, 11 Sep 2023 08:56:20 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

"Zack Weinberg" <zack@owlfolio.org> 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, *at all*; in
> many cases, not even if it is wrong. I find that people working on GNU
> tools often don't realize just how broadly used these names
> are. Changing the canonicalization of "CPU-VENDOR-mingw32", for
> example, is very likely to break things like Ansible playbooks and
> Travis-style CI build matrices -- one-off files that exist by the tens
> of thousands and there's no practical way to *enumerate* them all, let
> alone get them all changed to satisfy a GNU-internal desire for a more
> consistent naming convention.
>
> *Very recently introduced* names can be adjusted to correct technical
> errors.  For example, "CPU-VENDOR-windows-gnu" is a misnomer IMHO as
> there is no GNU libc port to Windows (see below); config.guess should
> not produce it and config.sub should not convert anything into it.
> But if the patch that had introduced this mistake were more than a few
> months old, we would be stuck with it, permanently.

This mistake is only two months old, thankfully.  I believe it can be
corrected without consequence.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]