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

[Jens Seidel <je...@users.sf.net>]

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 <je...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Neels J Hofmeyr <ne...@elego.de>]

Jens Seidel wrote:
> 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.

Yeah, it happened with me, too. I posted a patch and two weeks later no-one
had replied. Someone then said to me that the patch was probably not replied
to because no-one knew anything sensible to say about it at the time,
subversion being so large and complex. That helped me over the sort of
"naive disappointment" I felt... And now, basically a couple of weeks later,
I'm committing other people's patches already.

If I don't get replies, it helps me to just carry on in a relaxed frame of
mind, in subtle anticipation that someone out there, some release cycles
later, will discover the post and find exactly what she was looking for.

To me it looks like patches for mod_dav_svn, the build system and so on
usually aren't readily attended to, I guess because they require deep
insight into stuff most developers don't deal with most of the time.

Anyhow, I'm positive that all of your contributions are very much
appreciated by most of the developers (including me), even if one sometimes
gets a different impression. Thanks! And by any means, do continue!

~Neels

-- 
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696  mobile: +49 177 2345869  fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194