[csw-maintainers] Fwd: complicated build, subversion client

[rupert THURNER]

as the python bindings did not compile for more than 6 months, I commented
them for the first try of svn-1.7. but I d have a bad feeling if we let this
package further than unstable. any help to sort out that build error is
greatly appreciated.

rupert
 On Jun 2, 2011 10:06 PM, "rupert THURNER" <rupert at opencsw.org> wrote:

> On Tue, May 31, 2011 at 02:25, Ben Walton <bwalton at opencsw.org> wrote:
>
>> Excerpts from rupert THURNER's message of Mon May 30 16:08:35 -0400 2011:
>>
>> Hi Rupert,
>>
>> > You could separate out svnserve and other repository administration
>> > *binaries* (svnadmin, svnlook, svndumpfilter) into a separate
>> > package.
>>
>> This sounds like a good idea.  I've seen a few bug requests for it.
>
>
> stefan had the the convincing argument that we won't save any space on this
> as we need to deliver all the dependencies anyway as file:// needs to be
> supported see "libraries" below.
>
> my personal favourite as svn client currently is git. no svn necessary at
> all. just three commands are necessary:
>  git svn clone https://whatever
>  git svn rebase    # update
>  git svn dcommit   # commit
>
> > With the svn libraries it's a different story. You will want all of
>> > them on both the client and server. This means you'll need most (and
>> > probably all) dependencies on both sides.
>>
>> This would be a good subversion-common package.  Both the server and
>> client packages could then depend on it.
>>
>> > I suppose the LDAP dependecy comes from berkeley DB?  Subversion has
>> > no direct dependency on LDAP.
>>
>> Does checkpkg tell you it's a surplus dep?  If so, you could just drop
>> it.  It may be pulled in via something else and not actually be
>> required.  I haven't looked at it though.
>>
>> > You could also take a look at how the Debian packages for Subversion
>> > split things up. They probably have things split up as much as
>> > reasonably possible.
>>
>> It looks like a fairly monolithic setup there.
>>
>> > The files that don't compile with SUN's cc are generated by SWIG.
>> > Can you figure out if it's possible to make SWIG generate code that
>> > compiles with gcc as well as Sun's cc? If so we might be able to fix
>> > your problem by changing the way we generate these files.
>>
>> Might John's updated swig packages alleviate this?
>
>
>> >
>> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/0001-make-subversion-sysconfigdir-as-it-should-be-for-csw.patch
>> >
>> > That patch looks fine. If there is a pre-processor macro that
>> > identifies a CWS build we could also include this change upstream
>> > wrapped in the right #ifdef.
>>
>> Aside from the fact that this should be handled by autoconf (or
>> whatever build system they're using) instead of the way they're doing
>> it, I agree that the current patch shouldn't be too onerous to
>> support.  If they use autoconf and you'd like a hand building a patch
>> for that to make this sane, let me know.
>>
>> >
>> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/fixme.sh
>> >
>> > This I don't really understand.
>>
>> This may be replaceable by the 'STRIP_LIBTOOL = 1' capability that
>> Mike introduced to GAR, but I'm not sure.
>
>
> STRIP_LIBTOOL is there as well.
>
>
>>
>> > Note that as of Subversion 1.7 the build system will always use the
>> > libtool program that was used to compile APR. This was done so we
>> > could remove the configure script code for finding the right libtool
>> > and let APR sort this out for us instead.
>>
>> This should be a good change overall, I think.  That will likely mean
>> that it uses /opt/csw/bin/libtool (or whatever).  It may be possible
>> that the version of libtool changes between subversion releases though
>> since it won't be in lockstep with apr.
>>
>> > I suppose the above is something with the fixme.sh gone wrong?
>> > I've never seen an error like this.
>>
>> I'd suspect the same thing.
>>
>> Hopefully some of my feedback is useful too.
>
>
> many thanks, much appreciated :)  i tried removing fixme.sh, but it still
> goes wrong. let me copy the part out of libtool where it fails:
>
>        if test -n "$relink_command"; then
>           # Determine the prefix the user has applied to our future dir.
>           inst_prefix_dir=`$echo "$destdir" | $SED "s%$libdir\$%%"`
>
>           # Don't allow the user to place us outside of our expected
>           # location b/c this prevents finding dependent libraries that
>           # are installed to the same prefix.
>           # At present, this check doesn't affect windows .dll's that
>           # are installed into $libdir/../bin (currently, that works fine)
>           # but it's something to keep an eye on.
>           if test "$inst_prefix_dir" = "$destdir"; then
>             $echo "$modename: error: cannot install \`$file' to a directory
> not ending in $libdir" 1>&2
>             exit $EXIT_FAILURE
>           fi
>
>           if test -n "$inst_prefix_dir"; then
>             # Stick the inst_prefix_dir data into the link command.
>             relink_command=`$echo "$relink_command" | $SP2NL | $SED
> "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%" | $NL2SP`
>           else
>             relink_command=`$echo "$relink_command" | $SP2NL | $SED
> "s%@inst_prefix_dir@%%" | $NL2SP`
>           fi
>
>
>
> kr, rupert.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20111019/c5754ae2/attachment-0001.html>