Richard Stallman wrote:
>
> The most
> important example is when `configure' is re-run (which is not that
> uncommon; re-running `./config.status --recheck' when configure.in
> changes is becoming more and more common): any such variables set in
> the command line are lost in the re-execution, with unpredictable,
> usually bad, results.
>
> But options should be recorded in config.status so that they will
> not be lost.
>
Well, if you can record VAR=VAL settings in config.status, everything
is fine. And just to remind you, rms, the "open" syntax is needed for
we guys who do cross-compiling, since the "closed" syntax does not
allow to preset a few things - here it is atleast recorded in `automake`s
Makefile - the one that will implicitly call `./config.status --recheck`.
As the discussion does now lead a bit elsewhere, what about second-level
options, settable via VAR=VAL (or sth. alike)? There was the discussion
that for cross-compiling, people do often have the needs to preset
variables that are later stored in the config.cache (e.g. ac_cv_bigendian),
but nobody really knows their name until they read the configure source
code. May be its worth to support sth. like AC_OPTVAR(varname, helptext),
and the variable/helptext would not be shown unless called with an extra
option --help-vars (or sth. alike), and on the main helpscreen, just add
a line saying that VAR=VAL is supported and the exported varlist can be
seen with another help call.
By the way, the explicit AC_OPTVAR is not actually needed for the heap of
macros that do AC_CHECK_CACHE - they have the varname/msgtext relation
already in place, just need a generic way to export it to the local
commandline user (or those who run `configure` from a GUI-wrapper).
have fun
-- Guido.
