John Peacock <jpeacock@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
Received on Tue Mar 28 11:16:15 2006