(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.
PGP.sig (194 Bytes)
···
On 11 Apr 2005, at 18:43, Bob Aman wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04