On Sep 10, 2000, Richard Stallman <[EMAIL PROTECTED]> wrote:
> So since configure supports VAR=VAL, since this is a perfect scheme
> which is completely extendible, I was noting that this scheme was
> enough to support all the foodir variables we might need.
> 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
which doesn't work on all shells. Not even:
env VAR=VAL configure
is sufficiently portable, both forms have drawbacks. 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.
Supporting `configure VAR=VAL' is an important safety advance in
autoconf, and we'd rather not drop this feature. In fact, we'd
appreciate to have it included in the standards, so that it starts
being supported by other hand-crafted `configure' scripts. In fact,
it already is supported by some of them.
Besides, these changes are also upward-compatible, so they're not
harmful.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
