> We will stay with the --foo syntax for configure options. We should
> not change the configure syntax incompatibly unless there is a
> pressing need for a change.
Please reconsider. There is a pressing need for a change. People
currently have to use work-arounds such as:
VAR=VAL configure
I do not follow you; I do not see why people need work-arounds. Why
do you call them "work-arounds"? What job are people doing, and why
can't they use the --OPT=VAL syntax?
Why doesn't the decision to support --dir-foo=VAL solve this problem?
Supporting `configure VAR=VAL' is an important safety advance in
autoconf, and we'd rather not drop this feature.
I do not see why configure VAR=VAL is better than configure
--OPTION=VAL. It seems self-evident to me that it is possible
to make the latter do whatever the former can do.
Also, VAR=VAL is too general. We want to keep tight limits on
configure options. Every kind of option should have a standard
specified meaning.
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.
I have a feeling we are failing to communicate because of the language
barrier.
