autoconf
[Top][All Lists]
Advanced

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

Re: placing object files


From: Guido Draheim
Subject: Re: placing object files
Date: Sat, 14 Sep 2002 14:54:39 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

G.L. Grobe wrote:

When a project is compiling, instead of object files being placed in the top
level, what tells them where to get placed?

Also, how do I placed new libs, progs, etc... in a separate tree for built
finals so that the src and the build root dirs would be at the same level
and finals built from the src dirs would be placed in the build roots
hierarchy?

Any example projects around that do this?

(rtfm), `info autoconf`/"Multiple Architectures"
and use `automake` which will emulate VPATH everywhere.

mkdir build && cd build && ../src/configure

TO address@hidden:
 may be rename "Multiple Architectures" to "Multiple Builds",
 and add some more hints in the relevant section:

doc/install.texi

You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory.  To do this, you must use a version of @command{make}
that supports the @code{VPATH} variable, such as GNU @command{make}.
+or use a newer automake to emulate the vpath functionality.
@command{cd} to the directory where you want the object files and
executables to go and run the @command{configure} script.
@command{configure} automatically checks for the source code in the
-directory that @command{configure} is in and in @file{..}.
+directory that @command{configure} script is in that was just
+executed, and then checks for the sources in @file{..}.

If you have to use a @command{make} that does not support the
@code{VPATH} variable, you have to compile the package for one
architecture at a time in the source code directory.  After you have
installed the package for one architecture, use @samp{make distclean}
before reconfiguring for another architecture.

+Some build systems want to use configure in a separate build tree
+to keep the source directories free from generated build files. This
+makes diffing easier, and it allows to share the same sources for a
+parallel build on multiprocessor machines or when running multiple
+builds with the same sources mounted as a network share.









reply via email to

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