[geos-devel] [postgis-devel] RFC6 - Drop GEOS C++ API at GEOS 3.8

[Howard Butler]

> 
> On Oct 3, 2017, at 9:33 AM, Regina Obe <lr at pcorp.us> wrote:
> 
> 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.

I'm -1 on this. The library's contract with its users is not to take API away. The contract with the C++ API was you as a developer were responsible for ABI compatibility, not the project. The contract was never that the project reserves the right to arbitrarily pull the rug out from underneath you because it isn't convenient to one ecosystem of tools that can't keep their linkages straight.

What if we were to do the same thing with GDAL -- take away GDAL's C++ API which you were not supposed to use, but we put it out there anyway, because it was inconvenient for some of the open source packaging systems? Not possible because too many open source things in Deb/RH use GDAL C++ API, right? 

Defaulting the C++ API installation to off as the RFC currently proposes effectively removes it.