Strk, Is there a way to get rid of the shared C++ library and just have a C library or is that what you were talking about with the static C++ library.
That extra library I have to carry around annoys me as it's so easy for one to be overwritten and the other to be not. I'd love to just have one library to worry about that all applications that use the C-API link to. Not sure how other packagers feel about that. So in my perfect vision the following things would happen 1) Package Distributions would never compile with these flags 2) The end effect being, no C++ header, no C++ library to worry about -- just a single .so or .dll and a C header file 3) People building their own binaries or their own projects that utilize the C++ API will not be able to use GEOS from packages since GEOS packages will not have the C++ API bindings they need. They will have to compile their own GEOS. This means if they want their product to be shipped with other distributed software and share the same GEOS, they will need to use the C-API. That way new projects will be clear about what compromise they are making using the C++ API. That means they will not be able to use GEOS from packages in their CI integration (e.g. travis, appveyor etc that people commonly do apt-get ...) Are all in agreement with the above. If so can you rewrite the RFC to effect that intent. You have a better idea of what is possible or not with the GEOS code. Thanks, Regina -----Original Message----- From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of Sandro Santilli Sent: Tuesday, October 03, 2017 7:33 AM To: GEOS Development List <geos-devel@lists.osgeo.org> Subject: Re: [geos-devel] [postgis-devel] RFC6 - Drop GEOS C++ API at GEOS 3.8 On Mon, Oct 02, 2017 at 09:02:38PM -0400, Regina Obe wrote: > I've revised the RFC6 so hopefully it's more agreeable to everyone. > https://trac.osgeo.org/geos/wiki/RFC6 That RFC introduces a configure-time switch to enable installing C++ header, but doesn't mention installing C++ library, sounds inconsistent to me. Right now, the shared C library dynamically links to the shared C++ library, so we *must* always install the shared C++ library. But the static C++ library is only useful to those who can access the headers, so it woulnd't make sense to install it when not installing headers too. Maybe it could be: ./configure --with-cplusplus-sdk-install cmake -DINSTALL_CPLUSPLUS_SDK But still, packagers will still pass that flag, in order to build their packages, so I'm really not sure how this would help discouraging developers from refraining to use the C++ API... --strk; _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
