[Top][All Lists]

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

RE: access to m4 macros when configuring in subdirectories

From: David Byron
Subject: RE: access to m4 macros when configuring in subdirectories
Date: Tue, 9 May 2006 09:45:22 -0700

On Monday, May 08, 2006 Ralf Wildenhues wrote: 

<quoted out of order>

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

Your post just got this to sink in for me.  I was trying to keep the's separate since it felt better to have the autoconf logic
together with the modules that needed it instead of in one massive file.  Is there a way to include 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 together with their AC_CONFIG_SUBDIRS()
> links form an acyclic directed graph (tree); each
> that stands on its own (i.e., is not included by
> another, should be listed (with name Makefile)
> in AC_CONFIG_FILES of exactly one, otherwise
> havoc will ensue.

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

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

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


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,,  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's,'s), but I bet the normal way to
pull this off is to have one and one for both
and define two targets in  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.


reply via email to

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