AM_PRETTY_CMDS and unofficial macros? (was Re: [ANNOUNCE] libXmu 1.0.3)

[Kean Johnston]

> Where did you get this AM_PRETTY_CMDS (pretty-cmds)?
And more important, why on earth would anyone actually want to use it?
Its not like we have a large user community sitting doing interactive
compiles that they want to watch go by and who are being inundated
with "those pesky long command lines" as the doc talks about. Most
people who really compile X do it for a distribution, and such people
tend to *REALLY* Care about exactly what command line options went
into the compile and want detailed logs. Which leads me to ...

> Which makes me wonder ... should official xorg releases be using 
> unofficial macros?
I certainly hope the answer to that is a resounding, thou-shall-be-
spanked-if-thou-doest-it *NO*. This is one of the dangers of
modularization ... it allows the code base and the developer
experience to start drifting in a hundred different directions.
It is my opinion that there should be a standard set of autoconf
tools and versions that are used for all official releases. This
is *ESPECIALLY* true of stuff in lib/ which is sensitive to
libtool changes, and sometimes the difference between a working
platform and a broken one is the version of libtool you use.
This too is one of the dangers of the modular approach ... it
puts the "fate" of a working Xorg in the hands of projects
completely unrelated to X.org.

We can mitigate those dangers by selecting and standardizing
on a know set of tools. My advice would be for us to make the
"blessed" versions of autoconf, automake and libtool as part of
the utils directory, and have them be a pre-requisite for
making packages. These tools can all be configured with
something like --program-prefix=xorg, and then all tools which
need to regenerate the configure scripts can always use 'xorgautomake'
and 'xorgautoconf' etc so that they don't stomp on a possibly
later system version. Just a thought.

Post 7.2 I would like to work on exactly this, as well as
removing more dependencies on platform-specific ifdefs that
still exist in the code and making them all be autoconfiscated.
So that we don't drift too far from the rest of the herd, I'd
like to ensure that the full tree builds and works with:
automake 1.10, autoconf 2.61 and libtool 1.5.22.

Another advantage of having these tools be part of the base
Xorg build infrastructure is that it will give us a convenient
place to reliably patch the tools if needed, without waiting
for upstream to release new versions that may be the difference
between Xorg working or being broken.

Kean