libhttp

[Matt Zimmerman]

On Sat, Sep 22, 2001 at 12:37:29AM -0700, Ian Zimmerman wrote:

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

If any changes need to be made, configure.in and Makefile.am should be
adjusted so that the situation is automatically detected and handled
appropriately.  The average non-automake Makefile/Makefile.in for a complex
project with automatic dependency tracking is no less opaque to users than
the ones generated by automake.  At least with automake, there is a
high-level description in Makefile.am that can be easily understood.

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

This dependency is correct, since changes in configure.in can require
corresponding changes in Makefile.in.  autoconf will already be required in
order to recreate configure; requiring automake is not unreasonable.  If the
user is knowledgeable enough about automake that they can be certain their
changes do not require any updates to Makefile.in, they can just touch those
files.  Of course, such a user will probably have automake installed anyway.

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

This is true, and automake needs better support for other languages.  This
is incompleteness, not brokenness.

Support for Other Languages
===========================

   Automake currently only includes full support for C, C++ (*note C++
Support::)and Fortran 77 (*note Fortran 77 Support::).  There is only
rudimentary support for other languages, support for which will be
improved based on user demand.

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

The nice thing, of course, being that you could modify automake to use a
one-big-makefile-split-into-chunks strategy without modifying any of your
automake-based projects at all.  That is the value of abstraction.

-- 
 - mdz