Zack Weinberg wrote:
From: Zack Weinberg <z...@owlfolio.org>
The output now varies based on which of three different situations is
detected:
1. If config.guess’s embedded timestamp is more than three years old,
we instruct the user to update it from Savannah, and we don’t say
anything else.
2. If we tried to use a C compiler but none was found (not just in
the mips:linux case), we tell the user to try installing a C
compiler, and we don’t say anything else.
3. Only if neither of those is true will we print detailed diagnostics
and suggest contacting config-patches@gnu.org for assistance.
We still recommend checking for a newer config.guess first.
The duplicate uname -m/-r/-s/-v output is replaced with
diagnostics of the availability of uname and a C compiler.
I would suggest keeping the duplicate uname output; config.guess is
straightforward but lengthy and duplicating this output will help us
detect bugs in the script, should they mangle the UNAME_* variables.
There is a reason for those to be the very last thing the script outputs.
This won’t help the people who try to build tarballs from 2000 on a
CPU architecture that didn’t exist in 2000, but I hope it will help
the people twenty years from now who try to build tarballs from 2025
on a CPU architecture that didn’t exist in 2025.
(N.B. The Savannah URLs look a little too cgit-specific to trust
that they will still be good twenty years from now. Can we maybe
get the www.gnu.org admins to make /software/???/config.{guess,sub}
redirect to these URLs, just for a little extra future-proofing?)
I would agree that getting some stable redirects would be nice; archaic
versions of config.guess instruct users to update from Savannah CVS or
the main GNU release server.
Logically, the redirects would be at
www.gnu.org/software/config/config.{guess,sub} and would point to
Savannah cgit for now.
-- Jacob
