Building sources twice

[Joe Orton]

On Mon, Jan 18, 2010 at 11:10:34PM -0500, Toshio Kuratomi wrote:
> We have a few packages that need to build themselves from their sources
> twice.  For instance, vim builds three times (a minimal version for /bin/vi,
> and two versions with more dependencies for /usr/bin/vim and
> /usr/bin/gvim).  Working on the python3 Guidelines, it looks like we'll have
> some more with packages that build both python2 and python3 modules from
> source that undergoes an automated transformation as part of its build.
> 
> So there's approaches to doing this:
> 
> 1) Copy the source tree and build in both places
> 2) Build once with the python2 interpreter, copy the results away, and then
> build a second time with python3.
> 
> vim takes a C version of option #2 (build with one set of configure options,
> copy the results; make clean; and build with another set of options) but I'm
> not sure there's a reason for that.  It uses less disk space as we don't
> have to duplicate the source tree.  However, in software that might pollute
> its source tree when it builds (maybe substituting file paths directly into
> a source file, for instance), this could break.
> 
> Are there other reasons than I see for doing #2?

You should never be running "make clean" and rebuilding an existing 
source tree to produce a differently-configured binary, this will break 
debuginfo generation.

Most projects should allow use to use "VPATH" builds where 
srcdir!=builddir, if not it is generally pretty simple to fix up the 
Makefiles to support this.  Generally you'll do:

 mkdir build-one && cd build-one
 ../configure --some-options
 make
 cd ..
 mkdir build-two && cd build-two
 ../configure --other-options
etc

Regards, Joe