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

[Regina Obe]

Kurt,

 

Thanks for responding.  It's still on the table.  I just wanted to air out the issues.  

 

I was referring to install of headers.

 

Sandro et. al,

 

Getting back to your option with ./configure, would it be possible to only allow enabling of the C++ API if it's being built as a static library.  I think our main issue is when it's shared.

So if you link dynamically you'd be forced to use the C-API since you are impacting other possible application use.  If done statically, we don't care cause you are mixing your own soup.

 

The alternative thought is to start earnestly taking care of the ABI compatibility of the C++ API  and ensuring we don't recklessly break it.  

I don't think we should do that unless someone is willing to support the work or fund the extra effort to continually support it.

 

Thanks,

Regina

 

 

 

 

 

 

From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of Kurt Schwehr
Sent: Sunday, October 01, 2017 11:03 PM
To: GEOS Development List <geos-devel at lists.osgeo.org>
Cc: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [geos-devel] RFC6 - Drop GEOS C++ API at GEOS 3.8

 

-1 (non-PSC).  Please do not drop the C++ the C++ API.  Some folks (e.g. me at Google) statically link GEOS and ABI compatibility is not an issue.  Every build is a complete system.  Working with C APIs is far harder.  We end up having to wrap a C++ API back over C APIs.  But do note that I don't use any of the provided build systems.  It's unclear what you mean in RFC6 by not providing the C++ headers.  I presume that you mean in the install destination or do you just mean that packagers can drop the C++ header?

 

It's perfectly reasonable for packages to only depend on the C API and I think that does make sense for PostGIS.

 

On Sun, Oct 1, 2017 at 7:49 PM, Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

Okay I have created an RFC6 to officially drop GEOS C++ starting at GEOS 3.8  (so as soon as we release GEOS 3.7 (which should be next month), and flip the switch, we drop the C++ headers as well so developers won't be tempted to use them.

https://trac.osgeo.org/geos/wiki/RFC6


As Bas said already it causes packagers headaches.  It causes PostGIS headaches because users can't easily migrate to newer versions of GEOS because the packages they rely on e.g osm2pgsql (which is going away because we broke ABI with C++ aPI between 3.5 and 3.6).

If we can't support something, let's not provide it period.  It's disservice to everybody.

I know Sandro you think making it noisy would solve the issue.  Trust me it won't.  There is so much noise with all dependencies people compile with that most developers are trained to ignore them.
The proof to them is it compiles and passes their tests.  Unless of course you plan to introduce noise in production build, which makes GEOS useless anyway.


It is my understanding that only osm2pgsql (which is dropping GEOS anyway) and osmium which has already dropped GEOS, were the only big projects using the C++ API.  Lets not leave it in as that will just leave the whole open for newer projects to start using it.


As GEOS PSC member I vote +1 for dropping GEOS C++ API.


Thanks,
Regina





_______________________________________________
geos-devel mailing list
geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel





 

-- 

--

http://schwehr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20171001/990b2029/attachment.html>