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

[Regina Obe]

Well README on this page reads okay to me and says 

https://git.osgeo.org/gogs/geos/geos#client-applications  no stability offered for C++ API.
Anything you want changed there?


All my suggested changes to install Hobu and Mat booed so I think install changes are off the table.

I think the only other thing we can do is remind people in every release note that if they are using the C++ API they need to check their code before using it.  But not sure how many folks actually read release notes.

I really wanted it just turned off by default so lazy people who refuse to read wouldn't be using the C++ API, because in order to know how to use the C++ API, you have to read our warning first :)

So much for that effort.


Thanks,
Regina





-----Original Message-----
From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of Greg Troxel
Sent: Tuesday, October 03, 2017 8:35 PM
To: Sandro Santilli <strk at kbt.io>
Cc: GEOS Development List <geos-devel at lists.osgeo.org>; 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>
Subject: Re: [geos-devel] RFC6 - Drop GEOS C++ API at GEOS 3.8


(assuming the questions of whether to make any changes to the install, and to the README, are still on the table)

Sandro Santilli <strk at kbt.io> writes:

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

So when I create a geos package, do I turn on that switch or not?  When people build things from source, they can set switches.  But packages have to choose a way for all users, and it's messy to create multiple packages that behave like options being off and on.

And, installing the header does not cause the harm.  It's others using it.  I don't see geos having a install-headers switch causing other packages to decide not to use the C++ API.

> 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 :)

I actually kind of like this; perhaps even

#define WE_ACKNOWLEDGE_THAT_THE_C++_API_IS_UNSTABLE

or it doesn't appear.  But really this is all playing games, and should just be clear in the README.

My real point is that if geos means:

  We do not make any guarantees about the C++ API being stable across
  major releases.  Therefore, any program that uses the C++ API accepts
  an obligation to adapt to whatever new API appears, and to issue
  updated releases (on all upstream stable branches) within 3 months of
  the API-breaking geos release.

it should say it.

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

Static linking is discouraged, because it means that if you have a security issue, you can't just fix it and replace that package, but you have to rebuild anything that ended up with the static library, which means that you need a way to keep track of that.

And, at least pkgsrc wants to be able to build all packages starting from nothing, so statically linking an old version imposes the need to have the old version also in the packaging system.  (I get it that a depending package built before the geos upgrade would still work.)

There are packaging systems that make each package be essentially its own chroot with all the dependencies, so there are no conflicts for wanting different versions.  But I view that as a reaction to deal with API instability, rather than a desirable outcome.