[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r30864 - in trunk/contrib/server-side/svnstsw: . conf doc doc/man include include/svnstsw src

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: Mon, 05 May 2008 12:15:25 -0400

On Thu, 2008-05-01 at 13:43 -0400, Richard Hansen wrote:
> I wasn't aware that automake was such a hot-button topic. May I ask
> what the motivation was for removing automake? I'm a relatively
> inexperienced developer and it would be nice to avoid known problems in
> future projects.

I'll try to summarize:

  * automake assumes a recursive build system, and we wanted a
non-recursive one. Google for "recursive make" and the first match will
give some reasons to prefer a non-recursive build system. I don't find
them particularly compelling but some people do.

  * automake is an extra layer of complexity, which means an extra layer
to debug through when anything goes wrong. autoconf and libtool are in
the same boat, but unlike those two, automake isn't really *necessary*.
No one can easily duplicate the system portability jobs of autoconf and
libtool, but anyone can put together a build system without using

  * The stack of automake, autoconf, and libtool is poorly engineered in
that they are implemented in perl, m4, and sh, so you need to be
proficient in all three languages (plus Makefiles) in order to be able
to debug anything that goes wrong. Removing one of the layers of the
stack lowers this barrier.

I'm not a big fan of Subversion's solution; we've added our own
additional layer of complexity using our own additional language
(Python). However, we do get a somewhat auto-generated Windows build
system for our pain, which we didn't get from automake. And it's a
non-recursive build system.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-05 18:16:10 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.