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 <c...@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 _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel