[gdal-dev] GDAL 3.1.0 RC2 available
gdt at lexort.com
Sun May 3 12:33:27 PDT 2020
Even Rouault <even.rouault at 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
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.
More information about the gdal-dev