[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xougen] FW: imake status in Xouvert

From: Eric Anholt
Subject: Re: [xougen] FW: imake status in Xouvert
Date: Sat, 30 Aug 2003 00:49:24 -0700

On Sat, 2003-08-30 at 00:05, David Ross wrote:
Hey All Again,
> With respect to imake etc, what about autoconf?  I hear that it's
> support on alternative platforms isn't as good as imake.  Could we
> develop some sort of bridging util?  Pardon my ignorance, but I
> haven't had too much experience with imake/autoconf and we are going
> to be bound to get these questions so I want to put them in the FAQ.

[context lost to top posting]

The autotools suck.  I maintain a couple of ports (including XFree86)
for FreeBSD.  I fought for about a year with an
autoconf+automake+libtool+configure.in version issue working on glide
for FreeBSD.  Finally someone gave me a magic answer which fixed my
problem, though it didn't appear to be documented anywhere I could ever
find.  I have no idea how many hours I wasted trying to figure out why
libtool gave me some cryptic error message when I went to automake 1.5+.
(iirc it was the lack of placement of an unrelated, to my eye, automake
macro in the configure.in)

We have to maintain several versions of each of the autotools pieces
(autoconf, automake, and now libtool), so that all the various bits of
ported software can simultaneously be compiled in the ports system using
whatever versions of the autotools they require.  This of course breaks
many pieces of software people want to compile outside of ports because
those things expect "automake" to be the version of automake they want,
when in actuality they need to be calling "automake17," "automake15,"
etc. since automake is the name of whichever version works with the most
software (I forget at the moment).

And the autoconf tests that generally get written suck.  As a small
example, the basic macros aren't smart enough to notice that tcl is in
/usr/local or that gtk is in /usr/X11R6, since on linux most
everything's in /usr and nobody cares.  Oh, and we've added the version
numbers on the ends of many libraries and header include directories so
multiple versions can be installed at once.  So most FreeBSD ports need
specific instructions per port to say "tcl's here, libjpeg's here," if
it doesn't require more major surgery.  Then there's fixing the scripts
to include the prerequisite headers when checking other headers, fixing
for the name of our libpthread equivalent, getting it to respect the
system-wide CFLAGS and not the default according to autotools or
whatever l33t optimizations the software's maintainer put in, ...  Some
day I should write a script to see how many autotools-using ports there
are that *don't* require patches to build properly.

Could all of the various maintainers for different OSes get together to
rewrite XFree86's build to use autotools and be portable to the same
platforms?  Probably.  But I expect it'll require so many os-specific
hacks that it'll result in a mess that is slower to build and more
difficult to read than the existing, working imake build system.

Eric Anholt                                address@hidden          
http://people.freebsd.org/~anholt/         address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]