| For instance, if we do decide to support some --docdir, or --htmldir
| etc., in a large tree with several configures of different generations
| (which is always likely to happen), then outer configures might pass a
| --htmldir which an inner configure won't understand, and it will choke
| on it.
|
| configure scripts are supposed to ignore any reasonable arguments that
| they do not use.
This is *precisely* what I am talking about. --docdir is not
reasonable for any configure today. And it *must* die in this case,
which is right and what people want. It's already too easy to
misspell some of the --with and --enable options and not notice it.
| So it might be good to try to find an extensible scheme for directory
| specifications, something to parallel with --with and --enable.
|
| I agree. Perhaps --*dir should always be accepted, and ignored
| if it is not meaningful.
It seems that we succeeded to communicate: that's what I meant :)
| There are two ways to handle this: via `open options', just like
| --enable: we could recognize --foodir=FOO for any foo, or just using
| the fact that configure now understands
|
| ./configure variable1=value1 variable2=value2
|
| The spec says that configure arguments use --. Also that is what
| people are used to. I don't think we should change it.
Yes and no. Maybe I should have first told you that we are
encouraging people to
./configure CC=cc
instead of
CC=cc ./configure
because that's the only means when the configuration is refreshed to
remember CC was set: configure has to know it was given some special
values.
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.
| Meanwhile, option completion is a good feature and part of the GNU
| coding standards. It should continue to work.
OK. I agree I use it a lot with plenty of programs, but I believed
configure could be more picky about it. Who ever abbreviated some of
configure's options?
| Perhaps we should start accepting --dir-foo as well as --foodir.
| This would increase consistency.
You choose, you're in charge of this. Just tell us. But please,
recommend only *one* of the two (but we will support both, of course).
