libhttp

Ian Zimmerman itz@speakeasy.org
22 Sep 2001 00:37:29 -0700


Alan> I admit my ignorance to not even understanding them well
Alan> enough. This is the first thing I created that uses them, and my
Alan> main objective was to be able to configure the distribution for
Alan> various different targets to use the gnu cross compiler with,
Alan> and it did handle that pretty good. It seemed that
Alan> automake/autoconf/libtool all worked together in this
Alan> regard. How would I elliminate automake out of the picture so
Alan> this problem doesn't exist?

Matt> First, decide whether there really is a problem.  Automake gives
Matt> you a lot of useful things for free, and does the right thing in
Matt> many oddball cases that you may not have even considered yet
Matt> (have you used "make distcheck"?).  If you really don't want to
Matt> use it, all you need to do is write Makefile.in instead of
Matt> Makefile.am.

Now I guess it's time to explain why I hate automake :-) I don't
necessarily claim that the following reasons apply to Alan or his
project.  YMMV.

1 - Automake actually considers _too many_ oddball cases, which is the
prime reason that the generated makefile is so complex that, for the
installing user, doing almost anything else than the straight "sh
configure ; make ; make install" is usually out of the question.  One
such oddball case which shouldn't be considered is host systems
without symlinks, which seems to be the only reason for the GNU
srcdir/builddir distinction (hardwired into automake).

2 - The generated makefile includes a dependency of Makefile.in on
configure.in.  That means if the installing user has to modify
configure.in (something I had to do quite often in my pre-Debian days
when I compiled everything from source, to make tarballs install
cleanly), they must have automake on their machine (even if they never
touch Makefile.am).

3 - It is way too C-centric.  If your favorite language is, say,
ocaml, you end up writing almost a full Makefile.in anyway.  Of course
autoconf is C-centric too, but in this case you can just write your
own reusable macros to match your needs.

4 - It assumes a recursive make strategy.  So following the excellent
advice in

http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html

is very hard, if not impossible.

-- 
Ian Zimmerman, Oakland, California, U.S.A.
The easiest way to win an argument: ridicule your opponent's basic
assumptions by stating their negation and postfixing it with ", right?"
GPG pub key: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087