automake [Was: libhttp]

[Ian Zimmerman]

Matt> It sounds like you're arguing against VPATH, not against
Matt> automake/autoconf.  

I love autoconf, and I have nothing against occassional use of VPATH
where it solves more problems than it creates.  It is automake I hate,
for all the (wrong) assumptions it makes for me.

Matt> If you use symlinks instead of VPATH, you still have to make a
Matt> distinction between source files and derived files, in order to
Matt> know what must be symlinked to the build directory.  This seems
Matt> like more trouble than just using $(srcdir) where appropriate.

You make the symlinks _once_, before any building is done.  It can
even be done from configure.  The entire source tree is symlinked,
including derived files that come with the distribution.  If the user
modifies any source files (implying they have write access to the
source tree), the derived files are updated in place, which is the
Right Thing, and it is also the same as would happen with VPATH +
srcdir unless you deleted the derived file first.
  
Matt> What other complications are you referring to?  

I remember when I stopped using automake: I was trying to decide
whether to use $(srcdir) or not in a given dependency.  I thought for
minutes and minutes, and couldn't figure it out.  And I am a
programmer.  Now imagine someone who's trying to compile the package,
it breaks, and they have to play with the build.

Also consider all possible interactions with .PRECIOUS, .INTERMEDIATE,
.SECONDARY etc.  Are you sure you really understand them?

itz> 1 - Automake actually considers _too many_ oddball cases, which
itz> is the prime reason that the generated makefile is so complex
itz> that, for the installing user, doing almost anything else than
itz> the straight "sh configure ; make ; make install" is usually out
itz> of the question.

Matt> If any changes need to be made, configure.in and Makefile.am
Matt> should be adjusted so that the situation is automatically
Matt> detected and handled appropriately.

I think this is naive.  What if I want to rebuild just part of the
package?  A library, say?  Darn, just _finding the right target_ in
the Automake maze is a problem.

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

Matt> This dependency is correct, since changes in configure.in can
Matt> require corresponding changes in Makefile.in.  

Yes, but this is an artifact of automake.  The dependency is required
the way automake works; that is what I object to.

Matt> autoconf will already be required in order to recreate
Matt> configure; requiring automake is not unreasonable.

In the recent past, mutual version dependencies among autoconf,
automake and libtool were very fragile.  Getting the required version
of automake frequently meant upgrading -- or worse, downgrading! --
autoconf as well.

itz> 4 - It assumes a recursive make strategy.  So following the
itz> excellent advice in
itz> 
itz> http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html
itz> 
itz> is very hard, if not impossible.

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

I didn't say I hated abstraction, high level project description, or
even Makefile.am's as they are.  I said I hated automake, the
implementation.  And I think it would be highly nontrivial to modify
it this way.

-- 
Ian Zimmerman, Oakland, California, U.S.A.
Hypocrisy, arrogance and manipulation: sure-fire ways to earn hatred.
GPG pub key: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087