| > 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?
We are talking about a different issue. For instance people want to
override the default compiler ./configure will find, and it's been
years that INSTALL says to:
CC=sun4-cc ./configure
Hence, next time configure is run, it forgets about the CC which was
used to build config.cache, and you get an inconsistent system.
So configure needs the user to tell things instead of doing stuff in
its back. Hence
./configure CC=sun-cc
| Why doesn't the decision to support --dir-foo=VAL solve this problem?
It's a different issue. Since configure supports VAR=VAL, since this
scheme is by definition quite open, it will cover much of our needs
while providing two significant advantages: it will always be
compatible (passing totodir=bar to a configure that doesn't know about
totodir will not break anything), and we limit configure's code bloat
(configure is already quite a big beast).
