Some thoughts on the modularization effort

[Kean Johnston]

Hi all,

I'm a recent subscriber to this list so I have missed any history.
I've seen the initial stawman proposal quoted but haven't read it
in full from the archives yet. However, I have considerable
experience with the auto tools, and I think there are a few pitfalls
I can suggest you avoid, or if you decide not to avoid them, at least
are not surprised by.

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.

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.

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.

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.

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.

Kean