On Fri, May 17, 2019, 7:56 AM Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote:
> On 5/17/19 2:21 PM, Andrew Bell wrote: > > > Are you not rebuilding packages? > > Obviously we are. And that's the problem, new GEOS releases tend to > cause build failures for the projects that rely on the C++ API. > > Everything that relies on the stable C API doesn't need to be rebuilt > for new GEOS releases. > This implies that "stable" is the important bit. This is, IMO, a design issue, rather than one of a language choice, generally speaking. For people writing C++ there is real value in a stable and well-designed C++ library interface that simplifies development and potentially reduces bugs. This is an important consideration. For example, dealing with memory ownership for some C libraries can be trouble and can make for convoluted code. 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. > On Fri, May 17, 2019, 6:30 AM Sebastiaan Couwenberg <sebas...@xs4all.nl> > > wrote: > > > >> On 5/17/19 1:14 PM, Andrew Bell wrote: > >>> Why is this? There are many libraries that have C++ interfaces. > >> > >> Which also have difficulty providing a stable ABI. One that doesn't > >> change the symbols it exports with the new compiler releases, etc. > >> > >> Having a stable C ABI is a major plus for any project that uses C++ in > >> its codebase, it makes transitions to new releases much easier. A core > >> library like GEOS have many projects that require it, some are actively > >> maintained and implement changes quicky, others don't. And these make > >> life suck for distributions where all the projects need to be integrated > >> to work with the same version of GEOS. > >> > >>> On Thu, May 16, 2019, 11:37 PM Sebastiaan Couwenberg < > sebas...@xs4all.nl > >>> > >>> wrote: > >>> > >>>> On 5/16/19 11:28 PM, Mateusz Loskot wrote: > >>>>> I'd like propose to effectively revert the RFC 6: > >>>>> > >>>>> https://trac.osgeo.org/geos/wiki/RFC9 > >>>> > >>>> Please don't. We'll get more projects like OSSIM that break with new > >>>> GEOS releases, this causes significant delays before the new release > can > >>>> be included in distributions where lots of projects depend on GEOS > >>>> (which all need to build with the new release). > >> > >> 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@lists.osgeo.org > >> https://lists.osgeo.org/mailman/listinfo/geos-devel > > > > > > _______________________________________________ > > geos-devel mailing list > > geos-devel@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/geos-devel > > > > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel