maciej suggested to cross post the answer from stefan, dev@svn, to the question where our problem to compile the recent subversion might come from.<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>

From: <b class="gmail_sendername">Stefan Sperling</b> <span dir="ltr"><<a href="mailto:stsp@elego.de">stsp@elego.de</a>></span><br>Date: Mon, May 30, 2011 at 00:37<br>Subject: Re: complicated build, subversion client<br>

To: rupert THURNER <<a href="mailto:rupert.thurner@gmail.com">rupert.thurner@gmail.com</a>><br>Cc: <a href="mailto:dev@subversion.apache.org">dev@subversion.apache.org</a><br><br><br><div class="im">On Sun, May 29, 2011 at 11:19:05PM +0200, rupert THURNER wrote:<br>


> and we separate out the apache module, but imo a client should not contain<br>
> svnserve, svnsync, svndumpfilter, etc., see<br>
> <a href="http://www.opencsw.org/search/subversion/" target="_blank">http://www.opencsw.org/search/subversion/</a> for list of files we have<br>
> currently in subversion. currently we have sasl, ldap and berkely db<br>
> dependencies in this package<br>
<br>
</div>You could separate out svnserve and other repository administration<br>
*binaries* (svnadmin, svnlook, svndumpfilter) into a separate package.<br>
<br>
With the svn libraries it's a different story. You will want all<br>
of them on both the client and server. This means you'll need most<br>
(and probably all) dependencies on both sides.<br>
<br>
SASL is a dependency of svnserve (server-side implementation of<br>
the svn:// protocol) and of libsvn_ra_svn (client-side implementation<br>
of same). You'll need it on both servers and client if you want<br>
to support SASL authentication.<br>
<br>
You'll need berkeley DB on the server, and on the client for the<br>
libsvn_ra_local (file:// repository access protocol) to support<br>
Subversion repositories using BDB accessed via file://.<br>
<br>
I suppose the LDAP dependecy comes from berkeley DB?<br>
Subversion has no direct dependency on LDAP.<br>
<br>
> ... which seems bloat.<br>
<br>
Well, Subversion has a large set of features, some of which are optional.<br>
And with all those features come a lot of external dependencies.<br>
<br>
You could choose not to compile some optional features in to keep<br>
package dependencies down but I think that would be to the detriment<br>
of your users more than it helps them. You usually won't know in advance<br>
which features users of your packages will need.<br>
<br>
You could also take a look at how the Debian packages for Subversion<br>
split things up. They probably have things split up as much as<br>
reasonably possible.<br>
<div class="im"><br>
> > > 2. comlicated build<br>
> > > the build itself is so complicated that, since i can remember, we<br>
> > > continually fail to package a current version of subversion.<br>
> ><br>
> > Can you point out more specifically what problems you are running into?<br>
> ><br>
> > If there is something concrete we could do in to improve the build system<br>
> > we will consider it. Suggestions (and of course patches) are always<br>
> > welcome.<br>
> ><br>
> ><br>
> some files compile with the standard sun compiler, some don't, see:<br>
> <a href="http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/Makefile" target="_blank">http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/Makefile</a><br>
><br>
<br>
</div>The files that don't compile with SUN's cc are generated by SWIG.<br>
Can you figure out if it's possible to make SWIG generate code that<br>
compiles with gcc as well as Sun's cc? If so we might be able to<br>
fix your problem by changing the way we generate these files.<br>
<div class="im"><br>
> we patch certain files, see:<br>
> *<br>
> <a href="http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/0001-make-subversion-sysconfigdir-as-it-should-be-for-csw.patch" target="_blank">http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/0001-make-subversion-sysconfigdir-as-it-should-be-for-csw.patch</a><br>


<br>
</div>That patch looks fine. If there is a pre-processor macro that identifies<br>
a CWS build we could also include this change upstream wrapped in the<br>
right #ifdef.<br>
<br>
It's a very small patch though and doesn't really cause maintenance<br>
effort at your end, does it?<br>
<br>
> *<br>
<div class="im">> <a href="http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/fixme.sh" target="_blank">http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/fixme.sh</a><br>


<br>
</div>This I don't really understand.<br>
<br>
Editing Makefiles and libtool scripts like that is going to get you into<br>
trouble sooner or later, no doubt. This seems very hackish and hard to<br>
maintain. You are fixing up *generated* files. They going to change more<br>
often than not from release to release. It's probably easier to fix up<br>
the source files these were generated from, and regenerate.<br>
Preferably in a way that we can integrate upstream.<br>
<br>
Does CSW have a generic libtool replacement to deal with special<br>
requirements that you impose on shared libraries?<br>
OpenBSD does have one:<br>
<a href="http://www.openbsd.org/cgi-bin/cvsweb/ports/infrastructure/bin/libtool" target="_blank">http://www.openbsd.org/cgi-bin/cvsweb/ports/infrastructure/bin/libtool</a><br>
(It's only used for package builds -- my dev builds don't use this but<br>
they work fine on OpenBSD regardless.)<br>
<div class="im"><br>
> * (not sure if this is still active:<br>
> <a href="http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/javahl_headers_for_nested_classes.diff" target="_blank">http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/javahl_headers_for_nested_classes.diff</a><br>


> )<br>
<br>
</div>Note sure what the above is doing.<br>
<br>
> *<br>
<div class="im">> <a href="http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/subversion161.diff" target="_blank">http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/subversion161.diff</a><br>


<br>
</div>This is OK. We do similar things in OpenBSD. Unfortunately everyone has<br>
their own ideas about where stuff like python libraries should go.<br>
<br>
SVN should probably add a new configure script parameter to take away the<br>
need to patch this.<br>
<div class="im"><br>
> > > what would be a good way to address this in your opinion? would it be<br>
> > > possible to switch the build system to something easier to handle and<br>
> > > introduce proper dependencies?<br>
> ><br>
> > I don't think that smart handling of dependencies belongs into the<br>
> > Subversion core build system because there are so many different ways<br>
> > people manage dependencies on different systems.<br>
> > It would be very hard to come up with something that works for everyone.<br>
> ><br>
><br>
> autotools / libtool seems to be responsible for 80% of the problems. beside<br>
> making the build very slow we always need to tinker (see above), and still<br>
<br>
</div>I know that libtool is hard to deal with sometimes (I pulled some of<br>
my own hair out over it as well). But it serves a great purpose for<br>
Subversion because it is the most widespread way of dealing with<br>
shared libraries on many UNIX-like platforms. I don't think we can<br>
afford not to use it. If libtool is broken for you please try to<br>
get libtool fixed instead. This would also help you port other software<br>
that uses libtool more easily.<br>
<br>
Note that as of Subversion 1.7 the build system will always use the libtool<br>
program that was used to compile APR. This was done so we could remove<br>
the configure script code for finding the right libtool and let APR sort<br>
this out for us instead.<br>
<div class="im"><br>
> get errors like just now when trying to build 1.6.16:<br>
><br>
> cd subversion/bindings/swig/python ; /bin/bash<br>
> /home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.16/libtool<br>
> --mode=install /opt/csw/bin/ginstall -c<br>
> _<a href="http://core.la/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lion2.3/libsvn/_" target="_blank">core.la/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/install-isa-sparcv8/opt/csw/lion2.3/libsvn/_</a><br>


> <a href="http://core.la" target="_blank">core.la</a><br>
> libtool: install: error: cannot install `_<a href="http://core.la" target="_blank">core.la</a>' to a directory not ending<br>
> in /opt/csw/lib/python/site-packages/libsvn<br>
> gmake[2]: *** [install-swig-py] Error 1<br>
> gmake[2]: Leaving directory<br>
> `/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.16'<br>
> gmake[1]: *** [svn-python] Error 2<br>
> gmake[1]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk'<br>
> gmake: *** [merge-isa-sparcv8] Error 2<br>
<br>
</div>I suppose the above is something with the fixme.sh gone wrong?<br>
I've never seen an error like this.<br>
<div class="im"><br>
> but the subversion community is very nice and helpful which makes it still a<br>
> pleasure :)<br>
<br>
</div>Well, I hope my hints and suggestions will help. I'm sorry I don't have<br>
any conclusive answers to your problems.<br>
</div><br>