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

[Greg Troxel]

(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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20171003/eae08281/attachment.sig>