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

[Regina Obe]

Dale,

 

Yes would be interested in hearing what they have to say about name spacing.

 

What's your thoughts on strk's proposition which Bas thought was agreeable from a packaging perspective to just require a configure switch if building with C++

 

https://lists.osgeo.org/pipermail/geos-devel/2017-October/008054.html (listed below this message too)

 

I'm not sure why Mat dismissed it and got so angry.  

 

I'm willing to dispense with the static linking as it sounds like it might be too harsh of a compromise for those who control their whole environment.

Then again would be nice to have that option so that projects that insist on having the C++ api would use the named .so like geos-3.6 and the libgeos-c.so can stand alone with the 3.6++ or 3.7 embedded.

 

But I still think we at least need a configure opt-in to prevent developers from ignoring our ABI warning message.

 

Thanks,

Regina

 

  _____  

On Sun, Oct 01, 2017 at 11:19:48PM -0400, Regina Obe wrote:

 

> 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.

 

I was thinking of a more explicit --enable-c++-headers-install

(or similar)

 

And for the compile-time warning (which could be a first step),

it could be a warning that's spit at compile time and only if you

don't define some macro like:

 

  #define I_KNOW_I_SHOULD_NOT_BE_USING_GEOS_CPLUSPLUS_API 1

  #include <geos.h>

 

The warning will give an hint about the macro, ofc :)

 

> 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.

 

Static-only C++ library would mean statically linking it in

libgeos-c.so, which is currently dynamically-linked instead.

 

It could be a useful thing to do, but better gather more

opinions from packagers too.

 

--strk;

 

------

 

 

 

From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of Dale Lutz
Sent: Monday, October 02, 2017 7:59 PM
To: GEOS Development List <geos-devel at lists.osgeo.org>
Subject: Re: [geos-devel] [postgis-devel] RFC6 - Drop GEOS C++ API at GEOS 3.8

 

As someone who was around in the earliest of days of GEOS, I'd like to confirm that it was intended as a C++ port of the JTS (generally), and yes, to be used in PostGIS ultimately.

 

But from the first day it was a C++ project.

 

I do realize the nightmare that shared packages impose as things upgrade, which is why, again, as an old crusty guy that remembers DLL HELL of Windows, my starting point is that I want to control whatever libraries I'm going to rely upon.  So we don't rely on any pre-installed GEOS on any platform we deploy to -- instead we just link to our own library (which we prefix with our own name so we don't bump into anyone).  We do use the C++ API and so would expect it, in some form, to be available forever more.  I do realize there is a difference between what gets "installed" in a linux distribution and what a developer that wants to ship their own has.  

 

The team here suggested that namespacing the C++ API could be a way to avoid unexpected collisions -- I can ask them for more details if anyone is interested.

 

In short, though, we do rely on a C++ API and so I could not, in good conscience, vote to have it dropped.  A more nuanced proposal, which would separate those who link statically or "build their own" from those who rely on things in distributions, might be needed.

 

Dale

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20171002/59939265/attachment-0001.html>