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

[Daniel Stone]

On Sun, Dec 10, 2006 at 10:49:31AM -0800, Kean Johnston wrote:
> >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 ...

It's not enabled by default, and never will be.  It's not for the
funroll-loops crowd, but for use as a development tool.  Warnings now
stand out clear as the light of day (such as it is at 60°N in winter,
but I digress), and I find it incredibly useful when I'm writing new
code in particular: warnings never disappear.

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

I agree that this would be bad: xkeyboard-config, for example, has a
pretty bad configure script that badly needs attention.  But in general,
we're still quite harmonious.

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

Yes, but it also puts all the work in the hands of those who actually
_want_ to write a build system.  Of course, there's an argument to be
made along the lines of 'anyone who voluntarily writes build systems,
shouldn't be allowed to', but there you go.

The GNU/kFreeBSD (a marginal platform if ever there was one) and
GNU/Hurd guys worked around this by just patchin ltmain.sh,
config.guess, and config.sub, in all the packages before upstream
updated.  It wasn't terribly painful, and it's just one of the problems
you have to accept during porting.

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

I'm really not keen on blessed sets of tools, since it leads to us being
more involved in build systems again, and increases the temptation to
fork it.  Which would be a screaming nightmare.

I'm comfortable specifying _minimum_ versions of certain tools, however,
granted they're available in reasonable versions of common distributions
(i.e. we're not unnecessarily hindering developers).

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

Huzzah!

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

Given that 1.10 has barely been released, I'd be aiming for automake
1.7, or at least 1.8 (1.7 seems to have the widest deployment, and there
aren't any of the infamous forwards-incompatible changes that I know of,
beyond _SOURCES), and a slightly earlier version of libtool as well
(1.5.14?).

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

Please god, let's not do this.  Ever.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20061216/2d69f923/attachment.pgp>