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

[rupert THURNER]

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/20110602/b8b7be44/attachment-0001.html>