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 <sebas...@xs4all.nl> wrote: > On 5/17/19 4:43 PM, Mateusz Loskot wrote: > > On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg <sebas...@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 > email@example.com > https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________ geos-devel mailing list firstname.lastname@example.org https://lists.osgeo.org/mailman/listinfo/geos-devel