Some thoughts on the modularization effort

[Egbert Eich]

Adam Jackson writes:
 > On Wednesday 30 March 2005 19:15, Kean Johnston wrote:
 > > By the way, my comments about "./configure; make install"
 > > not just working are both almost always issues with libtool
 > > or automake or both. Those projects that avoid them are not
 > > thus afflicted.
 > 
 > These are not new sentiments, I've heard them many times.  I tend to agree 
 > with them too.  This is one area of the proposal that hasn't received much 
 > attention: when we do go with autotools, how far do we go?
 > 
 > libtool is overkill for X's needs.  The most complex thing we need to do in 
 > terms of DSO generation is not link the server modules against the system 
 > libraries, and specify precise sonames.  Every ld I know of has a pretty 
 > painless way to do this; on gnu toolchain systems, where apparently libtool 
 > works best, it's trivial, so why use libtool in the first place.
 > 
 > If we decide not to use libtool, Mesa's mklib script might be a better place 
 > to start.

There are already some autotooled bits of the X.Org tree that use autotools.
It may be interesting to see them built on non-Linux and non-BSD platforms
and get some 'numbers' which would help us making decisions on the libtool 
issue.


 > 
 > The automake argument I don't have as much experience with so I'd appreciate 
 > some input.  The modularised bits we have now use Makefile.am's.  How do we 
 > translate them to simple Makefile.in's?  Is there a positive benefit to using 
 > automake?
 > 
 > I'll throw out some data points here: modern linux systems ship with only two 
 > versions of autoconf, but as many as five versions of automake.  And by far 
 > the most common build problems people have with the modular bits we have stem 
 > from using the wrong version of automake.

I assume it would be possible to write Makefile.am's in a way that
they are usable with a wider range of versions of autotools.
We ought to set out guidelines (I actually remember discussing this
before so it may actually be in the modularization proposal) on
writing portable code and set up a validation environment (like
tinderbox) that ensures that these guidelines are met.
If we make the point that only components will be released officially
that pass this validation will be part of an official release 
the incentive to follow the guidelines should be pretty strong.

Cheers,
	Egbert.