[geos-devel] GEOS Ruby bindings gem and extensions

[Charlie Savage]

> My only thought is, "my, I know nothing about Ruby!". So, do tell me
> what needs to be in the main GEOS repo and who is going to need access
> to commit it. :)
In theory nothing - the idea would be move the ruby bindings outside of 
the geos source tree and have them live on their own and packaged as gem.

The advantage is that it becomes much more accessible to ruby developers 
because they could just do something like this:

yum install geos
gem install geos

And equivalent on Linuxes and OSX.  Windows of course would still remain 
more difficult.

That is actually how most ruby bindings to native libraries work - they 
aren't included as part of the native library itself.

The downside is that the different language bindings (ie python and 
ruby) go their separate ways. But that is already the case anyway...

Charlie
>
> Best,
>
> P.
>
> On Tue, Nov 30, 2010 at 6:49 PM, J Smith<jay at zoocasa.com>  wrote:
>> Alright, all, that wasn't too bad...
>>
>> Using the output from geos.i, I removed the version number constants
>> that get sorted out when geos.i is generated and which in turn is used
>> to generate geos_wrap.cxx. Instead of hard coding the constants at
>> build time, we can just use rb_eval_string during the extension
>> initialization to extract the version numbers from the Geos.version
>> method. For the GEOS_JTS_PORT constant, I noticed that the
>> GEOSjtsport() function isn't exported for the CAPI in geos_c.h, but I
>> extern'd it in the Ruby extension anyways to extract the version
>> information. Is GEOSjtsport() unsafe to use for such purposes? It
>> seems to be similar enough to GEOSversion() that it could probably be
>> available in the CAPI, no? If GEOSjtsport is unsafe to use I'll remove
>> it, though; I just wanted to retain complete compatibility with
>> existing constants is all. Is GEOS_JTS_PORT a particularly useful
>> constant? I've never had to use it, but then again I don't use JTS
>> myself directly. (As an aside, I also added a I've also ssws a
>> Geos.jts_port method similar to the Geos.version method.)
>>
>> At any rate, the version constants can now be created at extension
>> initialization so they won't be dependant the geos.i file any more and
>> SWIG can presumably be removed from the build process.
>>
>> Thoughts?
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel

-- 
Charlie Savage
http://cfis.savagexi.com