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