[geos-devel] GEOS Ruby bindings gem and extensions

[Paul Ramsey]

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. :)

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
>