Re: Simple "how-to" question, libtool

[Brian Dessent]

Mar Loh wrote:

> Q1: Every time I run ./configure from the topdir, the system checks
> (checking for BSD-compatible....) are re-run every time it gets to a new
> subdirectory, making the configure take a long time. How do I remove these
> checks when going to a new subdirectory (these are clearly redundant)?

This is the nature of a recursive build system.  The configure checks
may seem redundant but they're not, because in such a system each
directory with a configure script is a separate entity.  If the test was
not run again, the results would not be available in that dir.  The
traditional way in a recursive system that a higher level directory
communicates information to subdirectories is by passing arguments to
the subconfigure invocations, or invoking submakes with variable
overrides.

There is another simpler way, however -- the config cache.  If you
"configure -C" at the top level, this will create a config.cache file
there that stores the results of configure tests, or in fact any
variable matching *_cv_* (for cached value.)  This will also cause
configure to add "--cache-file=../config.cache" when invoking
subconfigures.  This causes the subdirs to share the cache.

A properly written test will do (at least) two things: it will store its
result in a variable in this *_cv_* namespace, and it will check before
doing any expensive work whether this variable is already set, and
bypass the expensive work if so.  The result of this is that a properly
written test will only do the expensive work once, and any subsequent
invocations -- either later in that configure script or in a different
configure script that is sharing the cache -- will just use the cached
value, normally printing "(cached)" in the output.

The cache is also useful when configure needs to be re-run, either
explicitly through the user invoking it or "config.status --recheck", or
when some dependency gets updated that causes the Makefile to do as
such.  The second run will use all the cached values for tests that are
cacheable, usually making it a lot faster.  Of course this is a double
edged sword: if the user is rerunning configure with significantly
different options or if the generated configure script has changed
semantically (e.g. the developer has edited a m4 macro) then the results
may be intentionally different in which case it would be necessary to
delete the config.cache file.

There are some situations where the cache cannot be shared: for example
if there are two configures that perform a similar test but with
different options/semantics.  If they both store their result to the
same variable and are sharing a cache, one will be incorrect.  Also,
some tests aren't properly written and don't effectively cache their
result.  But in general I don't think you need to worry unless you're
doing something really broken in your own macros, as all the ones that
ship with the tools ought to be cache-friendly.

There is another, more radical solution: nonrecursive build.  This
doesn't mean that you have to put everything in one large dir, or even
that you can't have all the build logic split off into per-directory
files.  Using includes you can still structure your files as in the case
of the recursive build, but in this scenario there is only one configure
script and one large Makefile that handles building everything.

> Q2: I'd like all *.h files to end up in /topdir/include/, with depth (e.g.
> topdir/libsrcdir/libsrcsubdir1/header1.h -->
> topdir/include/libsrcsubdir1/header1.h). How do I accomplish this? I've
> tried some things using top_srcdir, but I think I have the recursion messed
> up such that the local makefiles think that top_srcdir is whatever directory
> it's presently in, if that makes sense.

What do you mean "end up"?  The result of "make install" should put them
at their eventual destination on the end user's system, not some
location in the build dir.  Are you saying that you want the build
system to create a bunch of symlinks inside the build dir before
building anything?  What problem are you trying to solve?

> Q3: I'd like all *.la libraries to end up in /topdir/lib/, without depth
> (e.g. topdir/lib/lib1.la).

This goal very much goes against the end-user-centric philosophy that
the autotools try to foster.  In that vein, the output location is
whatever the current directory was when the user ran configure.  Also
called VPATH-builds (after the make feature used to implement it), this
allows for configuring in a location that is not necessarily the same as
the source dir.

This allows for a great deal of flexibility for the end user, such as:

- For a single source tree, you can have multiple build trees each
configured with totally different options or even on completely
different host architectures.

- The source can reside on a read-only network directory/filesystem and
still remain buildable.

- With a build tree separate from the source tree it is easy to simply
delete everything and start over without having to unpack the source
again or rely on "make distclean" being usable (e.g. in cases where you
don't even have a generated Makefile in every dir yet due to configure
problems.)

If the user has none of the above needs and simply runs configure in the
source dir, then the build tree is the same as the source tree as in the
traditional case.  But it's still important to conceptually think of the
build tree and the source tree as totally separate, and the resulting
libs/objects always go in the the build tree, whose location is
determined by the user.

I think you will get better help if you state what problem you're trying
to solve.  The "make install" step will take care of putting the
libraries where they need to go on the user's system, but that should
never be a location inside the source or build trees.  If you need to do
a simulated install for example to create a binary package, the right
method is "make install DESTDIR=/scratch/dir" which will populate
everything under /scratch/dir as if it were / of the user's system.  You
can then create a tarball of that whole tree which captures the
installed state of everything in your tree.

Note that automake does have the 'subdir-objects' option.  If you refer
in a Makefile.am to a source file in a subdirectory foo/bar.c, this
option tells whether the resulting object from that compilation goes
into foo/ or ./ in the build tree.  In a nonrecursive build system, this
allows to control whether you want to collapse the build tree into a
single flat dir or mirror the same structure as the source tree.  In a
recursive build system Makefile.am tends to only refer to source files
in that same dir so it has less of a meaning there.

Brian