Componentizing configure.in?

Derek Atkins warlord@MIT.EDU
04 Dec 2001 15:30:28 -0500


It works ok, but the problem is that you may wind up running some of
the same tests over and over again, because not all test results are
properly cached.

I've found that, in general, it is just as easy to maintain a single
configure.in as it is to maintain N configure.ins and a top-level
configure.in that knows about all the others.

-derek

Rob Browning <rlb@defaultvalue.org> writes:

> Bill Gribble <grib@linuxdevel.com> writes:
> 
> > 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.
> 
> Hmm.  I've had the same problem, though I wonder if by making sure all
> the sub-configures share the same config.cache, we might be OK.  I
> know that autoconf supports that, but I don't know how well it works.
> Just a thought...
> 
> -- 
> Rob Browning
> rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
> Previously @cs.utexas.edu
> GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD
> _______________________________________________
> 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