On 09/27/2007 06:59 AM, Michael G Schwern via RT wrote:
Show quoted text> <URL:
http://rt.cpan.org/Ticket/Display.html?id=29624 >
>
> peter@peknet.com via RT wrote:
>> What I ended up doing was just installing apr and apr-util manually, and then,
>> having finally wrestled the correct syntax from the Module::Build pod for how to
>> install in a non-standard location, Alien::SVN built and installed ok.
>
> Do you mean above and beyond just the normal Module::Build options or was
> Alien::SVN involved? Right now it's doing some guessing to translate between
> Module::Build's install options and configure's and perhaps that went wrong.
> I'm considering allowing the user to tweak the configure arguments.
>
I don't think Alien::SVN was involved. What I had a hard time understanding,
till I found Module::Build::Cookbook, was where/when I needed to add the
--install_base option to my command. Turned out it was at the initial 'perl
Build.PL' in order for it to be passed on to configure. (At least, that's what
I remember from yesterday, and perhaps that's the "guessing" you were referring
to.)
Show quoted text> What was the non-standard location and why did you put it there? I ask
> because right now it installs the svn shared libraries into $install_base/lib.
> It could instead install them into the Perl architecture-specific library
> directory under $install_base just like an XS module. This would keep the
> SVN::Core installed shared libraries totally separate from any other svn
> libraries.
>
I didn't have sudo/root on this machine, so I was trying to install stuff into
~/perl. Once I got the sytnax right, it did indeed put the svn libs into
$install_base/lib. But I think I would prefer them into the Perl arch libs, as
you say, in order to keep them separate. Then it would be obvious later what
the svn libs were doing in the perl tree. In my case, they ended up in
~/perl/lib, which wasn't exactly where I would have expected them.
Show quoted text>
>> After chewing on this for awhile, I'm not sure that I would want to depend on
>> the Alien::SVN approach for production rollouts, namely because by compiling
>> against an included copy of the svn libs, there's always a good chance that the
>> resulting SVN::* modules are using a different version of the libs than the svn
>> binaries are. Which would eventually bite me in the ass.
>
> No, SVN is very good about maintaining cross-version compatibility.
>
Well, I've been bitten half-a-dozen times in the last month by the case where I
have existing checked out files with svn 1.4.x but then try and manage them on
a machine with 1.3.x and no 1.4.x binaries available. svn 1.3.x refuses to work
with 1.4.x .svn layout. This happened when I had a shared file system where I
co'd on one box and tried to commit on another. I had to re-checkout using 1.3,
and then manually diff the 2 working areas and merge my local changes. Not the
end of the world, but inconvenient at the times it happened because I was under
deadline.
Show quoted text>
>> It's too bad that vendors don't just build rpms for all the swig bindings by
>> default. Maybe there are too many gotchas with swig versions, etc.
>
> Most Linux vendors do. Most have swig and apr and apr-util and libsvn and
> libsvn-perl and even svk as packages.
>
> Of which vendors do you speak?
>
In my case it was SLED 10.1. It could just be that this particular box had an
insufficient yum set-up w.r.t. which repositories it was searching. But I found
subversion bindings for python only. I did find apr and apr-util, but as I
didn't have sudo.... Well, you get the picture. root has its privileges. :)
Show quoted text>
>> I'm actually leaning heavily at this point toward writing a SVN::Class package
>> that subclasses Path::Class and implements the basic CRUD-like methods using
>> IPC::Cmd and the 'svn' binary. It's not as "clean" as using the swig bindings,
>> but will be more portable since it'll depend on the same svn command that normal
>> interactive use would. Sort of the ol' "PurePerl vs XS" issue.
>>
>> And since it's a different API than the SVN::Core stuff has (which mirrors the
>> svn C API so closely), SVN::Class could let you do:
>>
>> $file->commit('my message');
>>
>> which appeals to my database-oriented aesthetic.
>>
>> In any case, that's way off topic for this RT ticket. :)
>
> FWIW my purpose for SVN::Core is to make SVK easier to install.
>
Sure. Makes total sense.
Hope my comments are more help than distraction.
cheers,
pek
--
Peter Karman . peter@peknet.com .
http://peknet.com/
