| I'm OK with having as many --foodir as people might want (and
| actually, I'd like to suggest that we recommend
|
| ./configure prefix=/usr
|
| This is inconsistent with the normal command line option syntax.
| We should stay with -- for consistency.
Yes, I agree. What I'm trying to address is slightly different and
has to do with future backward compatibility.
Autoconf was designed so that configure accepts a limited and well
defined set of options, which is a good thing. But maybe we
underestimated the importance of being able to specify other
directories.
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.
So it might be good to try to find an extensible scheme for directory
specifications, something to parallel with --with and --enable.
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 problem with the --foodir approach is that people are used to be
able to use short forms for the options, i.e., they can use --bi
instead of --bindir for instance. I'm personally somewhat against
this in the context of configure since it makes it significantly
longer and more complex (option processing in configure is 10k, 255
lines mainly because of this, with this scheme I wouldn't be surprised
we reduce it to 2k).
If we release this constraint, then we can support --foodir for any
foo..
If we don't want to release this constraint/feature, then using the
variables seems a good track. I agree my example was wrong: I meant
bindir etc., not prefix which should remain as an option.
Please, note that I am referring to the compatibility between several
generations of configure, I am not trying to push to have a means to
let the maintainers add even more directory options to configure.
Nevertheless, this is a frequent request, and in some cases it is true
that the set of directory options provided by configure does not allow
the user to customize all the directories.
