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

Re: complicated build, subversion client

From: rupert THURNER <rupert.thurner_at_gmail.com>
Date: Sun, 29 May 2011 23:19:05 +0200

On Sun, May 29, 2011 at 20:16, Stefan Sperling <stsp_at_elego.de> wrote:

> On Sun, May 29, 2011 at 06:56:13AM -0700, rupert.thurner wrote:
> > for some time i participate in a small group of people packaging
> > subversion for solaris within the opencsw project. while we love to
> > use subversion a lot because it easily scales to terabytes of data
> > managed, we continue to have two problems building, for years now:
> >
> > 1. client build
> > personally i find it particularly difficult to separate out a "common
> > build", and "client build" and "server build" which both may depend on
> > it.
> Hi Rupert,
> You could build all svn binaries and then package them separately into
> client and server packages (with the mod_dav_svn Apache module depending
> on the HTTPD package). This is what Linux distributions and BSD systems do.

do you have an easy reference what goes into client, and what into server?
we use gar and are able to state which files go where, and have also
dependencies for every package:

and we separate out the apache module, but imo a client should not contain
svnserve, svnsync, svndumpfilter, etc., see
http://www.opencsw.org/search/subversion/ for list of files we have
currently in subversion. currently we have sasl, ldap and berkely db
dependencies in this package ... which seems bloat.

> > 2. comlicated build
> > the build itself is so complicated that, since i can remember, we
> > continually fail to package a current version of subversion.
> Can you point out more specifically what problems you are running into?
> If there is something concrete we could do in to improve the build system
> we will consider it. Suggestions (and of course patches) are always
> welcome.
some files compile with the standard sun compiler, some don't, see:

we patch certain files, see:
* (not sure if this is still active:

> > what would be a good way to address this in your opinion? would it be
> > possible to switch the build system to something easier to handle and
> > introduce proper dependencies?
> I don't think that smart handling of dependencies belongs into the
> Subversion core build system because there are so many different ways
> people manage dependencies on different systems.
> It would be very hard to come up with something that works for everyone.

autotools / libtool seems to be responsible for 80% of the problems. beside
making the build very slow we always need to tinker (see above), and still
get errors like just now when trying to build 1.6.16:

cd subversion/bindings/swig/python ; /bin/bash
--mode=install /opt/csw/bin/ginstall -c
libtool: install: error: cannot install `_core.la' to a directory not ending
in /opt/csw/lib/python/site-packages/libsvn
gmake[2]: *** [install-swig-py] Error 1
gmake[2]: Leaving directory
gmake[1]: *** [svn-python] Error 2
gmake[1]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk'
gmake: *** [merge-isa-sparcv8] Error 2

but the subversion community is very nice and helpful which makes it still a
pleasure :)

Received on 2011-05-29 23:19:57 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.