[adding bug-standards]
On 08/12/2012 08:12 PM, Daniel J Sebald wrote:
Hello Autoconf,
The Octave maintainers had a discussion about adding an option to
"configure" for a build directory. The reason is that a lot of people
like running configure from a directory other than the source tree so
that 1) object files end up in a different directory that can easily be
recursively removed to start over, and 2) multiple configurations and
builds can be done (the analogy being a debug and non-debug menu
selection in some C/C++ developer suite).
It was suggested this might be a generic feature rather than an
Octave-added option. So please give me your thoughts on adding this
option to Autoconf. By having this as an option, it lets people know
that a separate build directory can be done, and it might be useful down
the road to someone who wants to build a generic script. Patterning
after this:
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
it might be something like:
--builddir=DIR object and libraries
which is essentially the same as doing:
mkdir ../DIR
cd ../DIR
../<projname>/configure OTHER_OPTS
cd ../<projname>
We already document in the generic INSTALL file the possibility of using
VPATH builds to set up alternative build dirs, but you are correct that
the user has to pre-create the directory and start from that location.
Your idea may make sense, but I'd first like to have an opinion from the
folks that maintain the GNU Coding Standards [cc'd] on whether we should
require the syntactic sugar for automating the creation of a VPATH build
from within a different directory. That is, I don't see the point in
adding complexity to Autoconf to support this for every package unless
we first want to codify it into the GNU Coding Standards.
The other thing to realize is that VPATH builds tend to tickle bugs in a
number of non-GNU make programs, if they are not carefully written;
while we don't want to discourage VPATH builds, I worry slightly that
making VPATH builds triggered by a one-liner might backfire with more
reports of people having failed builds when they weren't familiar with
the risks of a VPATH build. The current status quo of having the user
take a several-step process to do a VPATH build tends to weed out some
of the cluelessness.