autoconf
[Top][All Lists]
Advanced

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

Re: AC_OUTPUT eats VPATH


From: Rasmus Tamstorf
Subject: Re: AC_OUTPUT eats VPATH
Date: Wed, 28 Feb 2001 20:20:03 -0800

On Wed, 28 Feb 2001, Derek R. Price wrote:

<--- snip --->

> Maybe that's not exactly what you wanted, but Autoconf is already set up to 
> handle it.
> Note that all the source files not generated by configure will still be under 
> topdir/,
> not topdir/arch?, and a properly constructed Makefile will still be able to 
> find them.
> The idea is that the build area will mirror the structure of the source area, 
> so
> topdir/arch1/src/package1 should have files built from sources in
> topdir/src/package1...
> 
> These aren't separate projects, are they?  Such that they could each have 
> their own
> configure script and a controlling Makefile that would cause a build to 
> descend into
> each arch-specific directory, run the appropriate configure script, and then 
> run each
> build?

No, these are not separate projects. Just subpackages in one big project.
- And I *am* aware that autoconf much prefers to do it the way you
describe. However, the idea behind trying to do it the other way is that
while you're developing the code (typically one of the subpackages at a
time) it's nice to be able to rebuild the code frequently and have easy
access to the result. If the objects get build into a subdirectory of my
code directory this means that I just have to put './arch1' in my PATH and
LD_LIBRARY_PATH to pick up my latest version. No need to do an
installation for each iteration of the code-debug-code cycle.
Alternatively, if I don't do an installation, but still want to pick up
the latest code I have to put something like ../../arch1/src/package1 in
the appropriate environment variables and I have to update that every time
I cd into a new subpackage which becomes quite a hassle. 

I can see the benefit of the way you describe in the case of code
distribution, because you can then have your code on a read-only
filesystem (CD-ROM or such) and still build it on a read-write filesystem.
However, I don't have such a constraint and my main concern is to make
developers as efficient as possible.

Maybe I'm missing something obvious though, so if anyone would like to
enlighten me about how to deal easily with the code-debug-code cycle using
a separate build tree, please let me know.

Rasmus

-----------------------------------------------------------------------------
address@hidden         "A problem worthy of attack, 
Walt Disney Feature Animation       proves its worth by hitting back" Kumbel
-----------------------------------------------------------------------------




reply via email to

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