You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mattias Engdegård <ma...@virtutech.se> on 2006/03/25 12:58:17 UTC
[PATCH] Correct path to Perl modules (issue 2479)
Sorry for the repost, but the Perl modules have been broken for such a
long time. Please apply, or tell me what is wrong with it.
I see no way this could be worse than what already is, in any case.
[[
Give Perl modules the correct run-time path (issue 2479); they should use
the installation directory, not just the build directory.
* subversion/bindings/swig/perl/native/Makefile.PL.in
Add libdir first in the run-time path.
]]
Index: subversion/bindings/swig/perl/native/Makefile.PL.in
===================================================================
--- subversion/bindings/swig/perl/native/Makefile.PL.in (revision 18963)
+++ subversion/bindings/swig/perl/native/Makefile.PL.in (working copy)
@@ -14,9 +14,13 @@
my $svnlib_builddir = "${top_builddir}/subversion";
my $swig_srcdir = "${svnlib_srcdir}/bindings/swig";
my $swig_builddir = "${svnlib_builddir}/bindings/swig";
+my $prefix = '@prefix@';
+my $exec_prefix = "@exec_prefix@";
+my $libdir = "@libdir@";
my @modules = qw/client delta fs ra repos wc/;
-my @ldpaths = ("$swig_builddir/perl/libsvn_swig_perl/.libs",
+my @ldpaths = ($libdir,
+ "$swig_builddir/perl/libsvn_swig_perl/.libs",
map {"$svnlib_builddir/libsvn_$_/.libs"} (@modules, qw/diff subr
ra_local
ra_svn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Correct path to Perl modules (issue 2479)
Posted by Philip Martin <ph...@codematters.co.uk>.
Mattias Engdegård <ma...@virtutech.se> writes:
> Unless, of course, everyone configure with --prefix=/usr (which I don't).
> In which case there is room for surprise when someone builds new
> modules using the same build path.
The perl bindings didn't get installed into --prefix when I last tried
to install them (some time ago admittedly), I would have needed to use
root to write into the perl tree. For that reason I've never
installed the perl bindings but I have installed the python bindings
which do install into --prefix.
>>I wish I had the time to go through the Perl binding in detail and
>>rework them to use a regular makefile and libtool (just for
>>convenience's sake for the rest of the project) so the bindings would
>>get linked to the right library all the time automatically. It may be
>>that using appropriately shaped LD_LIBRARY_PATH would do the job instead.
>
> Using LD_LIBRARY_PATH for testing is a good idea (if linking with
> --enable-new-dtags on Linux). For locating the installation libdir,
> LD_LIBRARY_PATH is much less attractive.
Using LD_LIBRARY_PATH for testing, putting the install directory in
rpath (only if it's non-standard perhaps?), and removing the build dir
from rpath all sound like good ideas, although there are portability
concerns.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Correct path to Perl modules (issue 2479)
Posted by John Peacock <jp...@rowman.com>.
Mattias Engdegård wrote:
> You have then installed the Subversion client libs where they are
> accessible by some other means (implicitly if /usr/lib or /usr/local/lib,
> or via $LD_LIBRARY_PATH). This is definitely not a solution for everyone.
Correct, but that is the most common installation, hence your statement
that "bindings that can be tested but WON'T WORK AT ALL once installed"
needs this very significant qualification.
I suspect that using EU::MM to generate the appropriate --prefix paths
and then messing with the 'install' target to relink the bindings using
the _installed_ Subversion libraries will be more fruitful.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Correct path to Perl modules (issue 2479)
Posted by Mattias Engdegård <ma...@virtutech.se>.
John Peacock <jp...@rowman.com> writes:
>Mattias Engdeg�rd wrote:
>> It's a lot better than having bindings that can be tested but WON'T
>> WORK AT ALL once installed, which is the present case.
>I don't understand this statement; I'm using the Perl bindings (1.3.0
>and 1.3.1-to-be) all the time (since I use SVK religiously). You may
>need to be more specific about how you are building the bindings (e.g.
>you are not be using the defaults??).
You have then installed the Subversion client libs where they are
accessible by some other means (implicitly if /usr/lib or /usr/local/lib,
or via $LD_LIBRARY_PATH). This is definitely not a solution for everyone.
Reasons to use --prefix include wanting to maintain/experiment with
different Subversion installations or just not being root on the machine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Correct path to Perl modules (issue 2479)
Posted by John Peacock <jp...@rowman.com>.
Mattias Engdegård wrote:
> It's a lot better than having bindings that can be tested but WON'T
> WORK AT ALL once installed, which is the present case.
I don't understand this statement; I'm using the Perl bindings (1.3.0
and 1.3.1-to-be) all the time (since I use SVK religiously). You may
need to be more specific about how you are building the bindings (e.g.
you are not be using the defaults??).
The other thing you should recognize is that 1.3.1 is being tested right
now so that the focus of the core developers is elsewhere. I would
strongly support improving the Perl bindings, including your other patch
to add new API's. It just so happens that SVK doesn't use those other
API's [yet], so the primary consumer of the Perl bindings hasn't needed
the additional API's.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Correct path to Perl modules (issue 2479)
Posted by Mattias Engdegård <ma...@virtutech.se>.
John Peacock <jp...@rowman.com> writes:
>I suspect your patch was warnocked[1] because no is really sure what is
>the "right" way to fix this problem and the Perl binding don't currently
>have a "champion" amongst the core developers.
So I fear, and the lack of bindings for API functions introduced in 1.2 or
later indicates this as well. Given that I have little time to dedicate
to maintenance of these bindings (my attempts so far have obviously failed),
I should probably switch languages. Would Python be better-maintained?
> Your fix suffers from the
>same problem as some of the other attempts, in that the bindings will
>use the already installed library files, rather than in the build
>directory. This can produce some subtle and difficult to catch
>problems. The current "best practice" is to build and install the Perl
>bindings before testing them (which isn't really a great idea, I must
>admit).
It's a lot better than having bindings that can be tested but WON'T
WORK AT ALL once installed, which is the present case.
Unless, of course, everyone configure with --prefix=/usr (which I don't).
In which case there is room for surprise when someone builds new
modules using the same build path.
>I wish I had the time to go through the Perl binding in detail and
>rework them to use a regular makefile and libtool (just for
>convenience's sake for the rest of the project) so the bindings would
>get linked to the right library all the time automatically. It may be
>that using appropriately shaped LD_LIBRARY_PATH would do the job instead.
Using LD_LIBRARY_PATH for testing is a good idea (if linking with
--enable-new-dtags on Linux). For locating the installation libdir,
LD_LIBRARY_PATH is much less attractive.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Correct path to Perl modules (issue 2479)
Posted by John Peacock <jp...@rowman.com>.
Mattias Engdegård wrote:
> Sorry for the repost, but the Perl modules have been broken for such a
> long time. Please apply, or tell me what is wrong with it.
> I see no way this could be worse than what already is, in any case.
I suspect your patch was warnocked[1] because no is really sure what is
the "right" way to fix this problem and the Perl binding don't currently
have a "champion" amongst the core developers. For example, see this
thread from last October:
http://svn.haxx.se/dev/archive-2005-10/0536.shtml
There have been several attempts to deal with the difference in the Perl
bindings (which don't use libtool to automatically link in the correct
libraries) as opposed to the other bindings. Your fix suffers from the
same problem as some of the other attempts, in that the bindings will
use the already installed library files, rather than in the build
directory. This can produce some subtle and difficult to catch
problems. The current "best practice" is to build and install the Perl
bindings before testing them (which isn't really a great idea, I must
admit).
I wish I had the time to go through the Perl binding in detail and
rework them to use a regular makefile and libtool (just for
convenience's sake for the rest of the project) so the bindings would
get linked to the right library all the time automatically. It may be
that using appropriately shaped LD_LIBRARY_PATH would do the job instead.
John
1) http://en.wikipedia.org/wiki/Warnock
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Correct path to Perl modules (issue 2479)
Posted by Mattias Engdegård <ma...@virtutech.se>.
Philip Martin <ph...@codematters.co.uk> writes:
>Does this affect the regression tests? Will the regression tests use
>installed objects instead of those in the build tree?
If there are old files in the installation directory that are intended to be
overwritten by the installation, then they will be used in preference to
the ones in the build tree. If this is not desirable, then $libdir could
be moved to after the build directory - but this is more dangerous, since
an innocent user might experience sudden malfunctions because the installed
modules he uses suddenly pick up files created in someone's build tree.
The best solution would be to hard-code the installation path only, and
override it when testing in the build tree prior to installation.
LD_LIBRARY_PATH could be used for that (at least if --enable-new-dtags was
used to link the module). The alternative is to remove the old installation
first - maybe that is less acceptable.
Anyway, as things stand now the modules don't work at all and I have to apply
the posted patch when I build a new SVN version.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Correct path to Perl modules (issue 2479)
Posted by Philip Martin <ph...@codematters.co.uk>.
Mattias Engdegård <ma...@virtutech.se> writes:
> Sorry for the repost, but the Perl modules have been broken for such a
> long time. Please apply, or tell me what is wrong with it.
> I see no way this could be worse than what already is, in any case.
>
> [[
> Give Perl modules the correct run-time path (issue 2479); they should use
> the installation directory, not just the build directory.
>
> * subversion/bindings/swig/perl/native/Makefile.PL.in
> Add libdir first in the run-time path.
> ]]
>
> Index: subversion/bindings/swig/perl/native/Makefile.PL.in
> ===================================================================
> --- subversion/bindings/swig/perl/native/Makefile.PL.in (revision 18963)
> +++ subversion/bindings/swig/perl/native/Makefile.PL.in (working copy)
> @@ -14,9 +14,13 @@
> my $svnlib_builddir = "${top_builddir}/subversion";
> my $swig_srcdir = "${svnlib_srcdir}/bindings/swig";
> my $swig_builddir = "${svnlib_builddir}/bindings/swig";
> +my $prefix = '@prefix@';
> +my $exec_prefix = "@exec_prefix@";
> +my $libdir = "@libdir@";
>
> my @modules = qw/client delta fs ra repos wc/;
> -my @ldpaths = ("$swig_builddir/perl/libsvn_swig_perl/.libs",
> +my @ldpaths = ($libdir,
> + "$swig_builddir/perl/libsvn_swig_perl/.libs",
> map {"$svnlib_builddir/libsvn_$_/.libs"} (@modules, qw/diff subr
> ra_local
> ra_svn
Does this affect the regression tests? Will the regression tests use
installed objects instead of those in the build tree?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org