Componentizing configure.in?

[Derek Atkins]

Is it really that bit a deal?  Most normal users should be using the
"stable" distribution which has already been autogen'ed.  Is there any
particular reason you can't autogen the code on one system and then
copy the sources to another?  Yes, I realize that that, too, is a
PitA.

If you go the modularization route, my only request is that
   ./autogen.sh
defaults to pulling in everything.

-derek

Bill Gribble <grib@linuxdevel.com> writes:

> 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.
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available