[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Different types of configure for same program

From: David Fang
Subject: Re: Different types of configure for same program
Date: Wed, 2 Aug 2006 03:17:18 -0400 (EDT)

> 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: ./ 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/with-readline            // --with-readline
        builds/with-editline            // --with-editline
        builds/with-bison               // YACC=bison
        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 (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.


        configure CC="ccache gcc" CXX="ccache g++" ...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]