On 11 Apr 2005, at 18:43, Bob Aman wrote:
> (Cross-posting to dev@subversion.tigris.org since at least part of
> this message is probably better answered by them. Apologies to the
> respective mailing lists for the parts that are off topic.)
>
>> Is DL unsuitable for this? That would require only a compiled SVN
>> library.
>
> DL?
DL is a generic dynamically-linked library wrapper that requires none
of this C compiler business. You load a so/dll and tell Ruby what the
parameters are for the C calls, and it takes care of all the argument
passing for you.
DL ships with ruby 1.8, but there doesn't seem to be an exact home page
for it.
http://www.google.com/search?q=ruby+dl
Will give you several tutorial/documents on it.
>> svn lists easily parseable output as one of its features...
>
> I don't think calling out to the command line client is a truely
> viable option.
Why?
> Ideally, I need a reliable interface to Subversion for Ruby.
If you build it to be reliable, it will be reliable. Unit tests come
in really handy for this.
> I want
> to be able to easily wrap it with something more "ruby-like" than the
> raw API.
There's nothing that prevents an svn wrapper from presenting a
ruby-like API. DL and SWIG only give different tradeoffs in how this
is implemented.
> Ideally, I need to be able to "checkout" to memory - I
> probably don't have the luxury of checking stuff out to disk.
While many of the svn commands can work directly with the repository
without local storage, I don't know of any way to avoid writing to disk
for those commands that require a local checkout.
> The
> ultimate purpose is something almost like ViewSVN or WebSVN, except
> that I need to, at the very least, be able to modify the metadata from
> within the web app. And we're probably talking about around 50-100
> concurrent users, not just one person at a time.
FreeBSD's CVSweb shells out for all of its commands, and likely handles
50-100 concurrent users just fine (probably more, in fact).
> It needs to be cross-platform.
This is easiest if you just shell out, since it will be easier to
maintain a svn wrapper than maintaining libraries for the platforms
that don't typically ship with a compiler (windows).
> It needs to be somewhat easy, because I am not a C
> hacker by any stretch of the imagination. And it's got to be
> reasonably simple to set up on Windows, since, for the moment, that's
> the dev environment I'm stuck with.
Sounds like you'd rather to an svn wrapper or DL (in that order).
> I've been trying to get the Ruby SWIG bindings to work, but I have
> absolutely no idea how to get SWIG to do its thing. It just sits
> there and complains about missing files.
DL or an svn wrapper will probably get you farther faster than SWIG,
since both have a lower barrier to entry. For an svn wrapper you just
need svn installed. For DL you need to be able to find an svn .dll or
.so, which may be as simple as installing svn. For SWIG you need
headers and a compiler, which can be no fun if there's no default
compiler and you have 2 or 3 different compilers to choose from.
> --
> E:\Ruby Projects\Libraries\ruby-svn\swig>swig svn_client.i
> apr.i(47): Error: Unable to find 'apr.h'
> svn_types.i(527): Error: Unable to find 'svn_types.h'
> svn_delta.i(91): Error: Unable to find 'svn_delta.h'
> svn_wc.i(116): Error: Unable to find 'svn_wc.h'
> svn_client.i(434): Error: Unable to find 'svn_client.h'
> --
>
> Of course, it doesn't help that building svn on Windows seems to
> require superhuman effort, though it's quite possible that I'm just
> missing some build step somewhere.
If you're having these difficulties, do you expect other people to find
it easier? Do you feel you can maintain what you've done when you've
completed your wrapper? These are important things to think about
before you put your hands on the keyboard. I have failed before when
trying to do something Too Big™ because I didn't think about how hard
it would be to complete.
> But for me to actually do what I want, this thing needs to all get
> packaged up in a gem. (http://docs.rubygems.org/read/book/1) Thus
> far, I've gotten the impression that even if I were to get this whole
> SWIG thing to work, the steps required to get there might be too
> difficult for rubygems to handle compiling from source. Which seems
> to leave me with precompiled gems? I don't know, I'm kinda fuzzy on
> this.
I believe gems work can ship both precompiled libraries or build their
own. I seem to recall that gems have setup.rb on the inside (or
something like it).
> I want this as the end result:
> gem install ruby-svn
> *poof, magic ensues*
An svn wrapper or DL are going to get you something that works fastest
and require the fewest incantations before the magic ensues.
> And I want that magic to ensue regardless of what platform I'm running
> on. If the user doesn't have subversion installed, I don't want that
> to be a problem.
I think that you'll be better off making this a requirement, I would
hate to be stuck duplicating the three different svn access protocols
(http/DAV, file, svn) or even one of them.
The subversion people seem to have done a good job of getting
no-brainer svn packages for all the major platforms.
> I want the only prerequisite to be ruby and
> rubygems. That includes build tools. If the user lacks SWIG or vc++
> or whatever, I don't want that to prevent the library from working. I
> think that leaves me with binaries, but...
Remember that you'll have to do the work of making this cross-platform,
which means keeping all the necessary packages up to date. That sounds
like a lot of work.
> It looked like the fxruby library did some stuff with SWIG and managed
> to pull it off fairly well,
I believe that Lyle has a good deal of C mojo in his back pocket, which
would make SWIG much easier for him.
> but I'm not sure I want users of the
> library to be presented with a list of 10 possible versions for
> different platforms when they type gem install ruby-svn like what
> happens with fxruby. Especially when one of those platforms is
> "ruby". Sooooo.... what happens with fxruby if I'm on Windows and I
> select "ruby" as my platform instead of "win32"? "ruby" doesn't make
> sense as an option, so ideally, I'd rather just have the end result
> work everywhere instead of confusing the user with nonsensical choices
> that I don't have much control over.
> Also, I don't want to be dealing with bleeding edge stuff from
> Subversion's svn repository. I have to make the corporate overlords
> happy, and you all know how that goes.
>
> So... is there any way for me to access the subversion client library
> without doing any SWIG magic, or at the very least, doing the SWIG
> magic ahead of time and then including any necessary binaries for the
> various platforms within a single gem? And if I'm absolutely stuck
> doing SWIG magic, can someone hold my hand and walk me through getting
> that to work in Windows? I've been trying to do this for almost a
> week now, and I'm really no further than when I first started.
Ruby SWIG wrappers for svn once existed, but bitrotted due to lack of
maintenance...
It sounds like you need to step back and re-evaluate all of the options
available.
SWIG seems to be more like a belt-fed, automatic, pneumatic nail gun,
and less like a box of nails and a hammer. Just about anybody can use
a hammer, but a belt-fed, automatic, pneumatic nail gun is going to
take lots of practice to use correctly. Once you have it down though,
you'll be able to pound out houses with ease. If you can invest the
time and energy to build SWIG bindings for subversion, then you'll get
a great tool.
If you can't invest that time, I would instead go for DL, or a wrapper
for svn.
Really, I think you should check out DL, you'll quickly cut your
problems down to those of actually wrapping the svn dll/so rather than
trying to figure out why SWIG can't find your apr or svn headers.
--
Eric Hodel - drbrain_at_segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Received on Tue Apr 12 11:30:27 2005