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

Issues with bindings tests

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 13 May 2014 03:57:24 +0100 (BST)

I ran into the following issues, testing the 1.7 and 1.8 releases recently. Some but not necessarily all of these are still a problem on trunk.

  1. JavaHL bindings tests tried to load the libs from /usr, if I had a Subversion dev package installed there.

  2. Perl bindings tried to install something to /usr/lib instead of to the configured prefix.

  3. Ruby bindings tests picked up my ~/.subversion/config. This can cause test failures, depending on my config.

Solutions:

1. serf.m4 lacks the "SVN_REMOVE_STANDARD_LIB_DIRS" that is present in (most of) the other .m4 files. A proper fix is to change build/ac-macros/serf.m4 like this (in two places):

-      LDFLAGS="$LDFLAGS -L$serf_prefix/lib"
+      LDFLAGS="$LDFLAGS `SVN_REMOVE_STANDARD_LIB_DIRS(-L$serf_prefix/lib)`"

This fix still needs to be applied to trunk, as far as I can see, although trunk's better support for 'pkgconfig' meant that this code was bypassed on my system (and the pkgconfig code worked fine).

2. A work-around is to install swig-pl like this (from Stefan Sperling's Makefile.svn):

  make install-swig-pl-lib
  ( cd subversion/bindings/swig/perl/native
    perl Makefile.PL PREFIX="$INSTALL_PREFIX"
    make install
  )

For swig-rb, we use 'configure --with-ruby-sitedir=...'. Should we implement a similar configure option for passing the Perl installation dir when building swig-pl?

3. A work-around is to run the swig-rb tests with something like HOME="$SOURCE_DIR/home" (which is a non-existent path).

For a proper fix, the swig-rb tests should use their own (empty?) config dir.

Does this all sound right?

- Julian

--
Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise
<http://www.wandisco.com/training/webinars>
Received on 2014-05-13 04:57:56 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.