[gdal-dev] libtool numbering policy

[Even Rouault]

Le mardi 14 juin 2016 12:13:49, Bas Couwenberg a écrit :
> On 2016-06-14 11:29, Even Rouault wrote:
> > 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 ?
> > 
> > If doing that, I can see
> > - pros: new policy would match the expectations of the C++ API users
> > - cons: C API users would see soname changes that don't affect them,
> > requiring
> > recompilation/relinking
> 
> As long as the C & C++ APIs are provided by a single library, it makes
> sense to base the libtool versioning on the C++ API since that changes
> most often.
> 
> In Debian we mark the libgdal C++ symbols and add a dependency on the
> version specific virtual ABI package provided by the libgdal20 package
> to all packages that use any of the C++ symbols. Most reverse
> dependencies of GDAL use (some) C++ symbols, requiring a rebuild of
> these packages for every new release of GDAL uploaded to Debian. Only
> the gmt, imposm, mapcache, mapserver, ncl, osmium, postgis, xastir,
> grass & pyosmium packages don't use any C++ symbols (10 out of 37).

Side remark: I'm surprised to not see QGIS listed in the C API only users. 
I've never seen use of the GDAL C++ API in it.
Same for Fiona & RasterIO

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com