[cairo] COPYING files....

[Dave Dodge]

On Wed, Feb 11, 2004 at 03:11:51PM +0100, Egbert Eich wrote:
> Dave Dodge writes:
>  > As a longtime victim of Sun's bundled imake configuration, I'll concur
>  > that relying on an installed predetermined configuration system is a
>  > recipe for disaster -- or at least long, loud cursing fits. I for one
>  > was extremely happy to see autotools being used for the new server,
> 
> This is a nice endorsement for autotools however it doesn't address
> any of my concerns at all.

True, I can't really answer your questions about the use of autotools
from the development side. 99% of my experience with this stuff is from
the user/installer perspective.

autoconf has proven its worth to me in that environment.  automake I'm
mostly indifferent to, as I don't deal with it directly. And I'm
currently reserving judgement on libtool, since I get the impression
that it might be the main culprit in cases where small applications
require insane amounts of disk space for compilation.

> It only degrades the Imake configuration shipped by SUN.
> I had the same problems with the one shipped with AIX by IBM.

Ah, AIX. I don't know about their imake, but I could rant at length
about Unix compliance (or lack thereof) in the older versions :-)

>  > since I know that 1) it usually works; 2) it usually does what I tell
>  > it; and 3) when it does misbehave it can usually be hacked/overridden
>  > without a lot of trouble.
> 
> 3 is also true for Imake - at least that's not a point that 
> speaks against Imake.

Again, it may depend on how imake was installed. The "fix" I finally
implemented for Sun's implementation (which according to my notes
didn't even seem to generate Makefiles compatible with its own
"install" program) required copying the entire config directory to my
home directory and messing with it several times, as each new package
I was building used some aspect of it I'd missed before.

One of the features of autotools from this perspective is that it's
self-contained in the package source tree. There's no external config
files on the installer's system that it's relying on to produce
Makefiles. So any hackery I want to do specifically for package X can
be done directly in package X's configure script, Makefile.in, or even
the generated Makefiles -- and I have a good bet that I can then do a
"make" and it will do what I expect. My recollection from imake is
that a "make Makefiles" stage would sometimes kick in and blow away
any changes I'd just made; or that I'd have to touch every Makefile in
the tree since they didn't inherit enough settings from the top
Makefile at build time.  But then I'm definitely no imake expert, so
there might have been an easier approach.

                                                  -Dave Dodge