Zack Weinberg wrote:
On Wed, Sep 20, 2023, at 9:59 AM, John Ericson wrote:
On Wed, Sep 20, 2023, at 6:01 AM, Dmitry V. Levin wrote:
Of course config.sub can provide a canonicalization of windows-cygnus
into cygwin if it helps.
I was worried that would close off the possibility of adding them as
normal forms later, but maybe it's better to just do it, if otherwise
we wouldn't support it at all.
+1 from me on the general principle that if LLVM accepts a name then
config.sub should know about it, and map it to an existing GNU name that
means the same thing, if any.
Agreed.
For what it's worth, we could imagine someday something like
--std=2024 to have versioned normalizations, allowing packages to opt
into doing the opposite normalizations
If you want to work on this, I suggest that your first step should be
to try to make config.sub and config.guess as table-driven as possible.
Right now, adding *any* sort of alternative mode for output is going to
be an exercise in frustration, since both scripts are big balls of mud
(in the classic sense of that term -- http://www.laputan.org/mud/mud.html).
Given the extreme limitations of portable shell scripting, this may only
be possible if you convert them to be generated from a more flexible source.
That is definitely not an actual problem. While config.guess is fairly
complex, the appropriate place for structured output logic is
config.sub, and that script currently gathers CPU, VENDOR, KERNEL, and
OS variables, then substitutes them into a template at the end of the
script. Supplying alternate templates will not be a problem. Further,
config.sub effectively *is* table-driven already, with several large
case...esac blocks.
I further argue that alternate output modes should only be supported at
config.sub; config.guess should always produce the current
hyphen-delimited tuple format.
-- Jacob
