Le mardi 14 juin 2016 14:16:51, Greg Troxel a écrit :
> Even Rouault <even.roua...@spatialys.com> writes:
> > A ticket ( https://trac.osgeo.org/gdal/ticket/6542 ) has been raised
> > about libtool SONAME having not changed between GDAL 2.0.X and GDAL
> > 2.1.0 due to incrementing both LIBGDAL_CURRENT and LIBGDAL_AGE .
> > This was raised also in https://trac.osgeo.org/gdal/ticket/4543
> >
> > Our, more or less implicit, policy up to now was to take just into
> > account the C ABI, and not the C++ one. Any opinion if we should change
> > it to take into account the C++ ABI as well ?
>
> I can see the point, but the other half of the situation is that
> packages do (or should) make a significant effort not to have ABI
> changes. With C ABIs, that seems to work pretty well. I have the
> impression that C++ ABIs are much more unstable, and they also seem to
> change in practice when changing compilers. So I am left wondering how
> much stability benefit there really is for C++ by adopting such a
> change.
>
> Would you expect a C++ ABI change every release?
Except for bugfixes releases, in practice yes for the yearly "feature" release
("feature" meaning here a change of major or minor in the "GDAL
major.minor.micro" scheme), as adding a new capability / virtual method, or a
new optional parmeter, etc... changes the C++ ABI.
--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
