[Xlibs] Re: [cairo] COPYING files....

[Egbert Eich]

Hi Dave,

Dave Dodge writes:
 > 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.

OK, from this perspective 'configure; make' may actually be simpler
to handle than a broken Imake build system.
Fortunately the Imake build system that came with XFree86 - although
far from being perfect - did work quite well.

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

Right. From the installer perspective Imake did more than necessary:
It did not only add the system dependent make variables but created
the entire Makefile.

 > 
 > > 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 :-)
 > 

AIX's Imake was at least as broken as the other vendors' Imake - 
at least in the days of AIX 3. I don't know if it got any better
later.

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

Yea, this sounds like AIX.

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

Yes, with Imake you would have to fix the Imakefiles instead.
However these files are just passed thru /lib/cpp to generate the
Makefile. Since the Imakefile is loaded at the end you could make
any necessary adjustments in the Imakefile. If things were going 
really bad you could add a hardcoded make rule to the Imakefile 
and it would show up in the Makefile.
This should be just as awkward as fiddeling with configure to
make it work. Fixing the Imake rules of course would be better 
- later builds would benefit from that.

Regards,
	Egbert.