>>>>> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Richard> What about other related Make variables, such as *dir? Should
Richard> they all be configure time options too?
Alexandre> Yes, and, in fact, they already are.
Richard> Not always. They are configure-time options in programs that
Richard> use Autoconf, and nowadays that may be most programs. But
Richard> *requiring* these options in the configure spec is still a
Richard> change, and it might require changes in some programs.
We are working a lot so that people can
tar zxvf ...
cd ...
=>> autoreconf
./configure
so that they can even have some form of guarantee the Makefile and
configure conform to the interface they know.
We should not use the past as an excuse to limit the future. DESTDIR
is a good example: there are still many package that don't support it,
or which support is broken, but it was a good thing to make.
Richard> It is not a very big or painful change, though, so I think I
Richard> should do something of that kind, once we work out the
Richard> precise details.
There is something I like better in
./configure --prefix=/usr bindir=/bin
over
./configure --prefix=/usr --bindir=/bin
the fact that it is clearer in the first case something special is
happening: `make install prefix=/usr/local' will not work
``properly''. There is something I like better in --bindir over
--dir-bin: it respects the names of the variables, hence the user does
not have to learn twice their names: once for ./configure, and then
for make.
Richard> Eliminating the possibility of specifying them at make time
Richard> would be a bigger change and an incompatible one. I think we
Richard> agree we should not do that, but we should encourage people
Richard> to specify these arguments at configure time instead of make
Richard> time.
Nope, I personally don't agree. Eliminating this possibility at `make
install' time is a very big change, I agree. We are talking about the
possibility of specifying them at `make', and what we are asking the
standards is to stop claiming it should work. Because it practice it
is not the case, and it requires quite some work from the
maintainers.
The maintainers are *tired* of fighting with Makefiles and
configure.in, they want something simple, efficient, that leaves them
some spare time to spend on the core of their packages. Any
simplification in this area is a means to help Free Software advance
by freeing the maintainers from the burden of adjusting tedious
details used by 0.01% of the installers.
