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