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

Build system flaws (Was: Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn)

From: Jens Seidel <jensseidel_at_users.sf.net>
Date: Wed, 22 Oct 2008 12:33:11 +0200

Hi Greg,

On Wed, Oct 22, 2008 at 01:48:41AM -0700, Greg Stein wrote:
> On Wed, Oct 22, 2008 at 12:49 AM, Jens Seidel <jensseidel_at_users.sf.net> wrote:
> >> Few things in software development are as obnnoxious as 'make
> >> distclean' running configure.
> >
> > Can this happen in a automake based project? I thought it just called
> > clean and removes also config.h, config.log, ... but as long as
> > configure.ac or a dependent M4 file isn't touched configure shouldn't be
> > called!??
>
> Yes, this happens. You type "make clean", and automake will re-run
> configure,

yes, if an autotools related file was touched. Cannot remember that it
happened otherwise. It can be avoided using the macro AM_MAINTAINER_MODE
which disables the so called "rebuild rules" by default but I don't
like it.

But this becomes off-topic and autotools stuff is indeed very
complicated.

> which rebuilds the makefiles, and then it restarts the make
> clean. After about the third time it did this to me, I threw out
> Automake.

OK.

> > But the current build solution is OK until nobody objects (no, I'm mean,
> > if everyone agrees ("+1") to patches) if one tries to fix remaining errors
> > (such as no parallel make support during install, or depending on an
>
> Hadn't heard about a lack of parallel support. Interesting. Do you
> know what causes that, or is there a bug filed where I can see more?

No, sorry I didn't investigated it yet as I wanted to start with a more
simple bug. (The problem is at least reported in the link mentioned
below.)

To be honest the build system never worked for me as user flawlessly
since years. For most of my problems I found solutions or workarounds
via Internet search so I assumed you know about these.

Here I think again that the rule not to create bug reports if not
aggreed on this list is not optimal. But now I'm at a state where I'm
familiar enough with the development of Subversion to provide patches
for hacking.html ...

> > properly installed Subversion during "make install" (see e.g.
> > http://www.nabble.com/make-install-doesn't-install-td19177330.html which
> > contains even a minor patch which can be applied if
> > include/subversion-1/svn-revision.txt isn't used (which I think is
>
> Missed that thread last month.

And all others too? It's strange that nobody had any opinion about
a build error. This one was sufficient simple so that I thougth it would
be optimal for starting contributing but I lost the interest without
replies.

Maybe my email writing style wasn't good enough (no PATCH: tag, not
starting new threads but replying to existing ones, ...) ...

> > true))). And there is of course also the problem that installation isn't
> > just a simple
> >
> > ./configure
> > make
> > make install
> >
> > but has to deal with subcomponents (such as javahl) differently and in a
> > fixed order.
>
> It's a complex build system at this point.

The solution could be a simple extension of the default targets by
sub-targets. Haven't tested it though.

> Originally, not everybody
> wanted to build the bindings and things. But I think your suggestion
> is better: rather than separate targets, make then configure-time
> switches.

Yep.

Thanks for your comments,
Jens

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-22 12:34:13 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.