Some thoughts on the modularization effort

[Daniel Stone]

On Wed, Mar 30, 2005 at 04:15:26PM -0800, Kean Johnston wrote:
> As a global comment, I'd like to state my $0.02. I am not sure that
> the effort of converting to autotools is worth it. I know folks
> have issues with Imake, but my experience, on a large range of
> platforms from AIX to Solaris to SCO to DG-UX to HP-UX has lead
> me to the same conclusion: Imake is simply much more robust. I
> agree it is a bit of a pain maintaining, and platform maintainers
> have to stay on top of things, but it gives you a degree of
> flexibility that the autotools don't. I can't remember the last
> time "xmkmf -a; make install" didn't work. I cant recall the
> last time "./configure; make install" *did* work. I fully realize
> that the autotools are the popular tools du jour, but forget not
> that they really have stood the test of time. The autotools are
> still undergoing constant maintenance. That in itself is something
> to consider.

I can remember the last few times make World broke, and the last few
times that autoconf invocations broke.  I can't remember autoconf
invocations breaking because of broken M4 or broken autotools; only
unfulfilled dependencies (e.g. go install libpng3-dev and come back
later).

I don't think constant maintainence (especially if it also entails
improvement) is a *bad* thing per se.  The platforms themselves (from
SCO through to Linux) are also constantly changing, and any build
system needs to keep abreast of this.  Imake as a preprocessor isn't
changing much at all, and realistically, neither is the core of GNU
autotools.  The rules for both are rather fluid, however.

> If the decision to go the autotools route is made, however, there
> are some things I'd dearly love to see us avoid. The biggest one
> *by far* is libtool. The second biggest is automake. The first,
> libtool, is just plain wrong is so many ways its not even worth
> considering. The only way libtool is useful is iff you are using
> Linux or FreeBSD, and you are using GCC, and you are using the
> GNU link editor. Despite efforts of the libtool maintainers to
> get it working on other platforms, it simply doesn't, except for
> very simple cases. Its not that libtool is buggy, its just that
> the architectural principles behind it are considerably incomplete
> and in some cases, just plain wrong. I could wax lyrical on the
> subject (and will, if asked), but my suggestion would be to
> have an xorg.m4 that we maintain, that platform maintainers can
> tweak and autodetect (or in cases where its appropriate,
> simply platform-detect) and set up macros like DLLDFLAGS, DLLD,
> DLCFLAGS etc. This allows for much greater scope in platform
> flexibility, and avoids many of the somewhat arbitrary and
> rigid libtool rules like their crazy version numbering scheme,
> *huge* shell script to execute on every compile or link etc.

I have to admit a relatively cushy position here: I work on Linux, the
two main libtool maintainers work on my platform (and sub-platform),
and the extent of my venturing outside the Linux world for serious
personal development use has been -- you guessed it -- FreeBSD.

So I haven't had any real problems with libtool.

What I have noted is that it really is the only way to portably generate
libraries, and haven't seen that many reports of it being broken (hell,
it works on OS X, which is pretty far away from Linux/FreeBSD).  It does
do a hell of a good job of generating shared libraries properly, and I
think that maintaining our own platform definitions is absolutely
nightmarish.

Think about it this way: if people aren't going to go fix a component of
autotools, which is a hugely popular build system, what are the odds
that they're going to fix the same thing in X.Org's own reimplementation
which no-one else uses, for their platform?

> The second case, automake, I just don't believe is necessary.
> It produces extremely verbose and difficult to diagnose Makefiles.
> I've written some pretty huge autoconf type things in my time
> and never once encountered a situation where automake would
> have done things either better, or quicker. Maintaining a
> Makefile.in isn't that hard. Its also a lot easier to debug.
> With a Makefile.am, the makefile that make uses is two levels
> removed fromt he source. With a Makefile.in its just one.
> Also, but just using a Makefile.in with some well documented
> standards, you gain considerably more flexibility. If you use
> automake, you are locked into their way of thinking, and for
> a project as complex as X, the more flexibility you have the
> less its going to cost you to implement.

They generate huge and overly verbose Makefiles, yes.  But the point is
that, unless you're debugging autotools or hacking on automake, you'll
never need to actually deal with those.  Everything you want to do can
be achieved by command-line options, tweaking the Makefile.am, or both.

> 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.

Interesting; ./configure doesn't invoke automake at all, it just
post-processes a bunch of Makefile.in's which automake happened to
generate.  I've not come across any problems here.

> If you do use the autotools, I have a small patch for autoconf
> that I've submittd but never seen accepted (nor seen rejected
> either) that makes the generated configure scripts more portable
> and less likely to overflow shell limits on older systems. Its
> a tiny patch and I'll post it here for those that are interested.

I'm interested in seeing this, sure.

See, for me, the main advantage of autotools isn't that it's
spectacularly good, to the exclusion of all others.  It is rather good,
and seems to work very well and very portably, and has an active
community upstream.  Platform maintainers are almost without exception
excellent at maintaining their definitions upstream, and it's far more
rigorous than we can ever, ever hope to be going out on our own limb.

But that's not why I like it so much.  My favourite thing about
autotools is that almost everyone knows it: the barrier to entry to
using, building, and developing has been significantly reduced.

I do have some problems and gripes with autotools, but on the whole I'm
pretty convinced that switching to autotools would be a change for the
better.  It's not a flawless solution, but it's a lot better than what
we have, and the best that I've personally seen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.x.org/archives/xorg-modular/attachments/20050331/2cecbe1f/attachment.pgp