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.
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.
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.
Arguments of the form VARIABLE=VALUE are not what people use. So that
would be an incompatible change. Also, it would be inconsistent with
the overall configure interface. That syntax is not intrinsically
bad, but I see no benefit that would justify the incompatible change and the
inconsistency.
Meanwhile, option completion is a good feature and part of the GNU
coding standards. It should continue to work.
Perhaps we should start accepting --dir-foo as well as --foodir.
This would increase consistency.
