Where is Buffy when we need her!?!
Soren A.
weeks with trying to use "autotools" with various packages.
I've concluded that this is one case where the `cure' is far more
iniquitous than the illness. Gnu "autoconf" is a potent and important
tool but its evil partner 'automake' is one of the worst atrocities to
ever be visited on the land of hackers. And gets my vote as the most
egregious misuse of Perl (its written in Perl) I've yet seen.
The makefiles which eventually result from using 'automake' are
monstrosities. Sheer hellish madness. Several dozen targets, named
obscene things like "am_remake_your_mother"; utterly counter-intuitive,
buried in 4 or 5 levels of indirection, swamped in a thousand lines of
baffling, migraine-inducing auto-generated superfluity.
The most recent release version of 'automake', 1.5 (?), produces
Makefile.in's that give rise to Makefiles that ought to be taken out
and bled to death slowly, shot, burned, staked through the heart,
generally Buffy-ated to the maximum possible extent. The heart of the
evil is the self-remaking recursion-loop insanity the Gnu folks have
succumbed to. The Makefiles will try to remake themselves and
everything else in sight spuriously and the whole mess is so fragile
that it will break at the slightest breath of breeze. Since the
remaking of itself (when a simple "make" is all that's requested!) is so
broken, non-robust, easily thwarted, you are left wanting to format
your hard drive just to purge the corrupt sticky gooey mess. If not go
on a protracted drinking binge.
Somehow in the stifling hermetic laboratory world that some of these
Gnu developers must have achieved, where everything is Gnu-perfect,
this must work, and these poor misguided, well-intentioned zealots must
have deluded themselves into thinking they've achieved something
useful. Think "Barney the purple dinosaur." Out in the real world of
individual quirky packages and problematical platforms their
hallucination breaks down horribly, reveals its true nature.
What is truly bizarre is that all this badness is committed in the name
of "portability." And equally bizarre is that underneath it all, it
appears that the perps must harbor a profound, perverse hatred for Gnu
`make', which if used correctly is a far friendlier, saner, cleaner
solution to the problem. `[g]make' has been ported to many platforms, is
Free, and the notion that some hypothetical user cannot have `gmake' but
CAN have the myriad of teensie tiny utilities and everything just-so,
that they'd need to run a `configure' (let alone work on extending a
package by using autotools), is sheer foolishness. Compared to learning
the arcane, non-intuitive (and often badly documented) rules of
`automake' and `autoconf', learning Gnu 'make' is a breeze. Gnu 'make' is
ONE program, vs. the phalanx of stuff one needs to have, to even run a
configure script (a non-broken UNI*-like shell, for starters, and sed,
awk, grep, uname, [...]). Somehow, this is a puzzling case where Gnu's
wisdom has taken a wrong turn into monumental foolishness. Lost sight of
the forest for staring fixatedly at the trees.
I repeat, for emphasis: automake is "evil" (no, I am not a relative of
George Bush {{FBI scan bait}}). It really is. Following the best
documentation available on how to set up one's package for 'automake',
with enormous care, one will discover that one has been made a patsy, a
victim of the worst sort of phony come-on, a time-wasting life-sucking
vampirical "there's a better way if you are willing to work hard {leer,
smirk, snicker}" hacker nightmare. I'd hate to see libpng become
embroiled in this miasmatic mess. Forget I ever wrote anything
suggesting anything like "autoconfiscate libpng." Nevermind.
Soren Andersen
Roger Leigh
> Posted today to PNG-Implement, following my nightmare of the last two
> weeks with trying to use "autotools" with various packages.
I understand from your post that you don't like the Makefiles
generated by autoconf.
All I can say is: ignore them. If you want to hand-craft yours, then
go ahead. automake is about automating it. You can easily extend it
using your own rules in Makefile.am. The automated regeneration /is/
logical. If it fails then it is most likely a problem with your
Makefile.ams.
As for autoconf, that is very useful (moreso than automake).
Detecting where all the programs needed for the build are located,
checking out all the needed libraries and testing the compiler and
associated tools is very useful. You can't do this with plain
`make'. Generating config.h is also good--you can conditionally
compile code depending on what features are available.
I suggest that if you hate automake, then just write your own
Makefile.in files and get autoconf to process those. i.e.
CC = @CC@
INSTALL = @INSTALL@
etc. You can pinch this from the top of a generated Makefile.in, and
write the rest yourself.
Have you tried autoconf 2.13 and automake 1.6, both released last
week. libtool may also be nice to use if you need to build shared
libraries (for libpng).
For a reasonably complex example, see the gimp-print tarball.
Regards,
Roger
--
Roger Leigh
** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers
Soren A.
> I understand from your post that you don't like the Makefiles
> generated by autoconf.
>
> All I can say is: ignore them. If you want to hand-craft yours, then
> go ahead. automake is about automating it. You can easily extend it
> using your own rules in Makefile.am. The automated regeneration /is/
> logical. If it fails then it is most likely a problem with your
> Makefile.ams.
Well, that is a source of my ire, since I've got myself pretty convinced
-- based on the amount of recent preparatory research including looking
at examples and documentation, that I've done -- I'm pretty convinced
that my Makefile.am's are correct. They are not too complex and yet
TTBOMK have all the target info needed by automake to get things right.
> As for autoconf, that is very useful (moreso than automake).
> I suggest that if you hate automake, then just write your own
> Makefile.in files and get autoconf to process those. i.e.
That's going to be my next move I think. Yes.
> Have you tried autoconf 2.13 and automake 1.6, both released last
> week. libtool may also be nice to use if you need to build shared
> libraries (for libpng).
Not tried; I thank you for the info although I don't think the stuff with
which I have the fundamental philosophical problem I have with what
automake is doing, will have changed at all in that incremental
sub-version-step. Gosh that was an awkward sentence, sorry.
> For a reasonably complex example, see the gimp-print tarball.
Thanks for your calm and positive reply to my somewhat rowdy posting ;-).
I salute you.
Soren Andersen
Roger Leigh
> Roger Leigh <rl...@york.ac.uk> wrote on 16 Mar 2002:
>
> > I understand from your post that you don't like the Makefiles
> > generated by autoconf.
> >
> > All I can say is: ignore them. If you want to hand-craft yours, then
> > go ahead. automake is about automating it. You can easily extend it
> > using your own rules in Makefile.am. The automated regeneration /is/
> > logical. If it fails then it is most likely a problem with your
> > Makefile.ams.
>
> Well, that is a source of my ire, since I've got myself pretty convinced
> -- based on the amount of recent preparatory research including looking
> at examples and documentation, that I've done -- I'm pretty convinced
> that my Makefile.am's are correct. They are not too complex and yet
> TTBOMK have all the target info needed by automake to get things right.
I have been hacking Makefile.ams for a couple of years now. If you
would like me to check them over, then feel free to contact me by
private email (or post them here, if you wish!). I can look at just
the Makfile.ams, or if you have a tarball available by FTP/HTTP, I'll
be able to test them too.
> > As for autoconf, that is very useful (moreso than automake).
>
> > I suggest that if you hate automake, then just write your own
> > Makefile.in files and get autoconf to process those. i.e.
>
> That's going to be my next move I think. Yes.
OK. I don't think that the new automake will make you happier--but it
is apparently more portable than before.