Componentizing configure.in?

[Bill Gribble]

I'm trying to build pieces of Gnucash on a platform that doesn't have
Gnome installed at all (an iPaq running Linux).  I don't really need all
that much of it... just the gnc-module system, really.  However, this is
a big PITA because in order to get a Makefile I have to run 'autogen' at
the top level and that requires all the Gnome stuff. 

There are a couple of different things I can do to get around this.  My
temporary workaround is to put an configure.in in the gnc-module subdir
which just has the stuff it needs.  That's fine, and if nobody else has
a problem with the current setup I'll continue to do it. 

However, I'd like to throw out there the idea of a more component-based 
top-level configure.in.  I have worked on projects with multiple
hierarchical configure scripts, and that's a non-starter ... it just
takes too damn long to run configure.  I was thinking something more
like having 'configure.include' components for subdirs of src/ which 
are fragments of configure.in.  We could modifying our autogen.sh to
take arguments specifying which subdirs to include the configure.include
fragments for and to add to SUBDIRS.  The default would be to include
them all, but if I just want to build the non-gui components I can do

  ./autogen.sh --with-components=gnc-module,engine

This would allow people to completely avoid tests for things that they
don't need if they know what they're doing but not get people in trouble
who don't care. 

b.g.