Zack Weinberg wrote:
On Mon, Sep 25, 2023, at 10:08 PM, Jacob Bachmeyer wrote:
Zack Weinberg wrote:
On Thu, Sep 21, 2023, at 9:49 PM, Jacob Bachmeyer wrote:
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.
That would preclude autoconf using the new format. We don't want to
have to run both config.sub and config.guess, only one or the other
depending on whether there were --build/--host/--target options on the
command line.
Passing each tuple through config.sub to canonicalize
and parse it should not be a serious problem.
Yeah, I partially take this back. I was concerned with the
maintenance burden, not the performance; in particular we do
not want to have to have
eval `config.sub --output=sh \`config.guess\``
because of the nested backticks. But if we could instead do
eval `config.guess | config.sub --stdin --output=sh`
then it would be fine.
Or better yet:
host=`config.guess`
# ... if --host not given on command line
eval `config.sub --parse=host ${host}`
# sets host_cpu, host_vendor, host_os, etc.
# (the argument to --parse is a prefix for the produced variables)
target=...
# ... TARGET is either set from --target or copied from HOST
eval `config.sub --parse=target ${target}`
# likewise sets target_cpu, target_vendor, target_os, etc.
The idea is that `config.sub --parse` would be called either way, either
to parse a guessed tuple or to canonicalize and parse a given tuple, so
it should be separate from the call to config.guess anyway. Autoconf
should already be separating parsing from acquisition here, so
delegating parsing to config.sub is replacing an existing blob of hairy
shell scripting instead of wrapping the config.guess call or argument
parsing.
There is also no real reason to ever have a parsed output format other
than KEY=VALUE, since that format is trivially parseable in any
reasonable language. Adding a prefix makes it easy to feed to the
shell's evaluator, which is config.sub's primary purpose of supporting
Autoconf.
The above examples omit "" around the variable substitutions, which is
permissible because no valid tuple contains spaces, however ""-quotes
may be needed if config.sub is to reject invalid tuples instead of
configure detecting when the argument to {--build,--host,--target} is
syntactically invalid because it contains whitespace.
-- Jacob
