[geos-devel] GEOS Ruby bindings gem and extensions

[J Smith]

Hey Charlie.

Just to start off with, as I believe you were the original author of
the SWIG bindings: thanks for the Ruby library! When we first
discovered it we were ecstatic, 'cause the Ruby-based solutions we
were looking at at the time were prohibitively slow. Nothing beats
native libraries (usually, at least), especially when you're dealing
with geometries that have potentially tens of thousands of vertices.

On Tue, Nov 30, 2010 at 7:08 PM, Charlie Savage <cfis at savagexi.com> wrote:
>
> Great - I think it would be a good idea to package this code as a gem so its
> more easily available to the Ruby community.  Will the gem also include the
> generated swig file (I'd say it probably should to eliminate the extra
> dependency on swig) or have you ported the code to just a straight ruby
> extensions?
>

At the moment I just took the SWIG files and am generating the
geos_wrap.cxx file as per the original build, but thinking on it a bit
more, it doesn't really seem necessary. One of the potential problems
with the SWIG files is that some Ruby constants are filled in at build
time rather than run time, and that could become problematic -- if you
built the gem against GEOS 3.2.0, for instance, but later upgraded the
library itself to GEOS 3.2.2, your Ruby gem would still be reporting
the 3.2.0 version numbers as it was built.

What I think I'll do is just generate the geos_wrap.cxx file from the
SWIG files and use that along with some additions to handle extracting
the version numbers from the GEOS library at run time rather than at
build time. I see that the geos::geom::geosversion() method will
return the GEOS version and in the CAPI GEOSversion() function will
return the CAPI information. I think that would be enough for the
version numbers to be extracted, yeah? I'll give it a shot at any
rate.

> Ok, I've done something similar.  Happy to move over to these.  They are in
> Ruby code I assume?
>

All of the extensions are in plain ol' Ruby code.

> How about two gems.  One for the geos bindings, and then a separate one for
> rails.  That way people don't have to have the extra rails code if they
> don't want it.
>

I think the plan at the moment is two gems -- one that strictly builds
the GEOS binary and a separate one that contains all of the extension
code plus the Rails integration. The Rails integration is pretty
compact and only gets included when Rails tries to use the gem, so
normal Ruby should never feel the effects.

I'm going to mess around with the generated SWIG code and see what I
can do about removing SWIG as dependency and get the version numbers
working. Once we're ready, I think we'll be posting the project to
github and open things up for patches before we roll releases, just to
give everyone a chance to take a look at the code and make sure it's
sane. Hopefully we'll be ready to do so within the week, so wish us
luck.

Cheers...

J