[geos-devel] RFC 9: Restore C++ API as public API

[Kurt Schwehr]

I'm a developer and a package manager (inside Google and somewhat still
around for fink on mac)...

I count on both the C and C++ APIs for many projects.  Projects needing ABI
stability know they need to stick to C interfaces.

For those of us packagers that "live at head" (well mostly...), we know
that ABI stability is out the window and it's up to us to manage things
carefully.

I've been successfully doing C++ management with GEOS and GDAL for many
years.  It seems reasonable for debian to only support C, but please don't
rule out C++ for others.  For me, C++ APIs are radically better than C for
large scale work (aka google) and I really really don't want more
custom/external to the package C++ wrappers for C (with or without wrapping
C++).

On Fri, May 17, 2019 at 10:34 AM lnkansa <lnkansa at gmail.com> wrote:

> NON PSC:
> While I do appreciate the work of the library developers, I do support
> that fact that C++ API is made available for the larger community. C++ is
> enjoying Renaissance (11, 14, 17, 20) and attempts to "force" downstream
> developers to use the the C-API rather decreases programmer productivity. A
> good example would be the use of unique_ptr for resource management - it is
> as good as it gets. Why not just use it as it is intended? After all, there
> are always a thousand ways to compile a library with different compiler
> switches. That is a beauty and also a pain - This is what partly defines
> our DNA. Stable projects would always use CAPI knowing the consequences.
> Anyone who opens up the hood should know what he is doing and if the person
> shoots himself in the foot so be it. Those using C++ would have to compile
> anyway. OSS projects that take such dependencies are the ones that should
> pay the price and not the other way around. If their usage breaks your
> packaged distro, they should pay the price of being dropped. After all
> engineering is about choices. Please bring the C++ API back a first class
> citizen.
>
> On Fri, May 17, 2019 at 4:53 PM Sebastiaan Couwenberg <sebastic at xs4all.nl>
> wrote:
>
>> On 5/17/19 4:43 PM, Mateusz Loskot wrote:
>> > On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg <sebastic at xs4all.nl>
>> wrote:
>> >> On 5/17/19 3:23 PM, Andrew Bell wrote:
>> >>> Frequent, breaking API changes seem a problem. ABI changes seem more
>> like a
>> >>> small annoyance. I can understand how a stable ABI would be nice, but
>> I
>> >>> personally don't think it's more important than a good interface for
>> >>> library users.
>> >>
>> >> And that's the difference in perspective between a developer and
>> >> distribution packager.
>> >
>> > It is not my role of a library developer to make packaging easier.
>> > There are many PMs and PDMs, OS-specific, distro-specific
>> > as well as number of OS-agnostic ones. It is not a library developer
>> > role to promise an easy life to maintainers of any of the PMs/PDMs.
>> > It would be a sisyphean task.
>>
>> That's not very considerate.
>>
>> If GEOS becomes too painful to maintain, I'll remove it from Debian to
>> keep my sanity, and leave it up to users to build it themselves and
>> integrate it with the other packages.
>>
>> If that requires the removal of other packages that require GEOS, so be
>> it. That just reduced the number of packages I have to maintain. It's
>> not in the best interest of our users, but fuck them too, right?
>>
>> Kind Regards,
>>
>> Bas
>>
>> --
>>  GPG Key ID: 4096R/6750F10AE88D4AF1
>> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
> _______________________________________________
> geos-devel mailing list
> 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/20190517/f7ec298c/attachment.html>