RE: access to m4 macros when configuring in subdirectories

[David Byron]

On Monday, May 08, 2006 Ralf Wildenhues wrote: 

<quoted out of order>

> If you're going to merge the Makefile.am's, or include one
> into the other, be sure to do the configure.ac merge first.

Your post just got this to sink in for me.  I was trying to keep the
configure.ac's separate since it felt better to have the autoconf logic
together with the modules that needed it instead of in one massive
configure.ac file.  Is there a way to include configure.ac fragments?

> Maybe you can show more of your setup, so we can understand
> package specific constraints.

I'm starting with a system of homegrown makefiles.  Lots of directories,
lots of recursive make invocations.  As well, there's a central
directory where include files get "installed" to.  That's the directory
in the include path.

When I add a new directory, I use automake/autoconf.  Each
automake/autoconf directory is completely independent at the moment.
And, they follow the same convention of #including header files from the
central location.  To pull this off I pass --prefix to configure and run
a make install.  This breaks the dependency information and more stuff
gets rebuilt than is necessary.

I can resolve this by adding the paths where the header files live
before installing them (and taking out the install operation).  I
figured I would give a shot to the full-on non-recursive make at the
same time.

> the configure.ac together with their AC_CONFIG_SUBDIRS()
> links form an acyclic directed graph (tree); each
> Makefile.am that stands on its own (i.e., is not included by
> another Makefile.am), should be listed (with name Makefile)
> in AC_CONFIG_FILES of exactly one configure.ac, otherwise
> havoc will ensue.

Makes sense.  If I'm including Makefile.am fragments, I need to make
sure there's only one AC_CONFIG_FILES([Makefile]).

> Wait.. you have a configure.ac for each directory?  That is
> really rare.  Usual setup is to have one configure.ac per
> software package, and a bunch of Makefile.am.  More than one
> configure.ac is only necessary or useful to
> 
> - bundle rather independent packages (also to remain rather
> independent)

Here's an overview of what I've got.

top/app_1
top/app_2
top/related_libs_1
top/related_libs_1/lib_1_a
top/related_libs_1/lib_1_b
top/related_libs_1/lib_1_c
top/related_libs_2
top/related_libs_2/lib_2_a
top/related_libs_2/lib_2_b
top/related_libs_2/lib_2_c

No shared libraries.  Everything statically linked.  When we release
something, it's either app_1 or app_2.

Let's say app_1 links with lib_1_a, lib_2_a, and lib_2_b.  app_2 links
with lib_1_a and lib_2_c.

When people work, they typically either work on app_1 or app_2.  Either
way they get all of related_libs_1 and related_libs_2.

If I treat all the lib_*_* as totally independent, everything pretty
much works.  I configure, make, make install in each directory.  But,
too much stuff gets rebuilt because everything depends on files in the
install destination and those timestamps change because the install
recipe makes a new copy every time.

As I said above I think I can fix that, but the other benefits of one
big Makefile are tempting.  Ideally I'd like one big one for app_1 and
one for app_2.  Note that there's nothing in the top directory at the
moment...No makefile, Makefile.am, configure.ac...nothing.  It's a
consequence of the way we're using revision control.  I can't put
anything there.  (Each of app_1, app_2, related_libs_1, and
related_libs_2 are clearcase VOBs.  The top level directory isn't in a
VOB so nothing can go there.)

I bet as I add more autotools-aware libraries that I'll be duplicating a
bunch of configure tests.  It would be nice to avoid that as well.  I
guess I can share cache files...Not exactly sure what my options are
here, especially with the top of the directory tree forbidden.  If I
have to move everything around, I'll consider it, but I'm not sure what
a good solution is.  I can make a giant VOB with everything in it so the
top level becomes a valid place to put files.  My reflex is to have
app_1 and app_2 not know anything about each other (i.e. have totally
separate Makefile.am's, configure.ac's), but I bet the normal way to
pull this off is to have one configure.ac and one Makefile.am for both
and define two targets in Makefile.am.  Is that right?

Sorry for being long-winded.  If you've gotten this far and have some
suggestions I'd love to hear them.

Thank you.

-DB