Re: Different types of configure for same program

[David Fang]

> Sometimes I wish to call configure with different flags. For example:
> ./configure CXXFLAGS="-ggdb -Wall -std=c++98"
>
> or
> ./configure CXXFLAGS="-O3 -funroll-loops" --with-gmp
>
> or some more like these. Having to be writing these all the time is
> cumbersome and error-prone since for debugging or for long line of
> flags and configure options I sometimes forget what I want.
>
> What's the 'common' way to solve this problem?
>
> I though about scripts, like: ./configure-for-debug.sh or
> ./configure-with-gmp... etc.. but I'm curious about how other people
> work this out in their on projects.

Here's my two-cents:

In addition to keeping such scripts handy, I also use a subdirectory for
VPATH builds (assuming Makefiles were written with it in mind.)  e.g. (in
the source root directory)
        builds/gcc-3.3                  // "CXX=g++-3.3"
        builds/gcc-3.4
        builds/gcc-4.0
        builds/gcc-4.1
        builds/gcc-4.2
        builds/powerpc-darwin
        builds/i686-linux
        builds/i686-freebsd
        builds/with-readline            // --with-readline
        builds/with-editline            // --with-editline
        builds/with-bison               // YACC=bison
        builds/m32
        builds/m64                      // CFLAGS="-g -O2 -m64"

As is the case for VPATHs, I find it very convenient to update my sources
in one location (e.g. CVS) and building in each build-directory (invoking
configure as ../../configure)  Since the build directories don't conflict
with each other, I almost never have to clean them, save for the
occasional distcleancheck.  I leave maintainer-mode off, so that the first
of these rebuilds in any of the build directories will regenerate
configure and Makefile.in (in srcdir), config.status --recheck, etc. (in
build-dirs) automatically.  Reconfiguration is reasonably fast using a
config.cache (-C).  Before I prepare the source for any release, I have
scripts to visit each build-dir (varies depending on machine/OS) to
configure && make && make check (best run overnight).

I really appreciated that the whole build system is able to regenerate
itself automagically, which saves a lot of time in the learning process.
For even more performance improvement, I ccache [1] all compiles so
configurations that vary only in small ways will have many translation
units compiled identically, and transparently reuse previously compiled
objects where appropriate.

I am quite happy with the GNU autotools build system and its conventions.

Fang

[1] http://ccache.samba.org/
        configure CC="ccache gcc" CXX="ccache g++" ...