Even Rouault <even.roua...@spatialys.com> writes: > Answering Bas' > >> If you don't want that, then two libraries need to be built with their >> own library versioning. > > and Gregs' > >> This doesn't make sense. The current/revision/age needs to be handled >> differently for the C library and the C++ library, because in feature >> releases one of them does not have an ABI break and the other one does >> have an ABI break. They will then not have the same shlib major >> numbers, which is an obvious consequence of the above versioning policy. > > Separating a C library from a C++ one would represent a big deal of work, as > there are C > symbols called from C++ code, so that means that when currently there's a C > function like > GDALInvGeoTransform(), there should be a C++ one, like > gdal::InvGeoTransform() that does > what GDALInvGeoTransform() does, and GDALInvGeoTransform() would call this > one, and > make sure all code from drivers etc that calls currently > GDALInvGeoTransform() would call > instead gdal::InvGeoTransform(). > Anyway this isn't a discussion for this release, but more for a GDAL 4 or > more.
If the ABI changes you have to bump the shlib major. Or, you have to have some special, irregular rule, that says the C++ ABI is unstable despite the shlib staying the same, or a special rule that says the C++ ABI is private and may not be used. >> > I'm not sure about the resolution here. Should I do a RC3 that sets >> > CURRENT/REVISION/AGE to 27/0/0 ? Would that help ? >> >> I think it would be really unfortunate to break the C ABI as a side >> effect. That would change your policy above that there is (perhaps) an >> ABI break on feature releases. > > The C ABI of GDAL 3.1 is the same as GDAL 3.0. But if I bump the CURRENT > number, as there's > just one lib, it will apply to the C and C++ side of it obviously. So I can > imagine that's slightly > inconvenient for people that just depend on the C ABI and wouldn't need to > rebuild, but I'm > afraid there's no way to make everybody happy. This is the nature of using C++ :-( >> Even better would be to keep the C++ ABI stable. > > Not doable. Sometimes you need to add a new virtual method for exemple, like > was done for > 3.1. At least for this relase, there should be a paragraph in NEWS that very clearly explains the API/ABI change situation with respect to previous releases and whether shlib majors have changed, and any deviations from norms. Maybe that's there, but Bas seemed surprised by this. I admit that I don't usually see this, but I think statements of API/ABI compat belong in NEWS and should be super clear. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
