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

[Regina Obe]

>> On 10/03/2017 07:37 PM, Howard Butler wrote:
>> 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? 

Just curious how many projects that rely on GDAL use the C++ API are distributed by packages.

> Those projects would be forced to adopt the C API just like for GEOS.
> And that would make life for distributions much easier as well, especially since GDAL has many more reverse dependencies than GEOS.
>  Because of the importance of GDAL to most projects, they will be sufficiently motivated to port their project to use the C API.

> Kind Regards,

> Bas
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1 _______________________________________________

I will say this much.  Right now we don't have too many projects that are distributed using a shared GEOS library not using the C-API.

The ones mentioned -- Kurt  (Google) and Dale (Safe)
Both package their own GEOS and don't trust their stuff sharing libraries with other software.
They know the risks, asking them to add an extra switch to use the C++ API is not the same as taking away the C++ API.  Your comment is a bit exaggerated.

I put lots of configure crap when I build GDAL just cause I have to do something like --with-sqlite=... doesn't mean my ability to use SQLite is essentially taken away from  me .

The other GEOS that are shared, use the C-API and we really want to keep it that way since we have the bandwidth to support that.  
We don't want to get into a state like GDAL where lots of projects are happily being distributed and using the GEOS C++ API with no guarantee of long-term stability.

If GEOS can not guarantee the same kind of longevity of the C++ API/ABI that it can for the C-API, it shouldn't be 
encouraging developers to use it by allowing it in its default behavior. 

BTW that's the same reason I shot down the idea of a shared liblwgeom, 
I knew that we as PostGIS project did not have the bandwidth to support it as a shared thing, so we didn't want anyone using it but us.
And if you really went thru the effort to do so by cd'ing into our folder, you're clearly  on your own.


Thanks,
Regina