GDAL Driver Changes

[paulbaker78]

--- In gdal-dev at y..., Frank Warmerdam <warmerdam at p...> wrote:
> I think it is unwise to depend on the C++ API remaining binary
> compatible between versions. It should generally remain compilation
> compatible. Retaining binary compatibility in C++ APIs is very
> difficult, as even adding a new virtual function at a location other
> than the end of a class can cause binary incompatbilities. Fixing
> const correctness issues is another example of a seemingly harmless
> changes that foils C++ binary compatibility (as I realized to my
> horror after changing the OGR API for const correctness issues).

This is exactly what SONAME is for, which we talked about in the other
thread I started a week or two back. This is really important that it
should probably be worked out by the next release (1.1.8? 1.2.0?
2.0.0?) so that people can start to rely on it. IMUIC, that means gdal
should install something to the affect of:

libgdal.so.<release_version>
libgdal.so.<binary compatibility version or SONAME> which is symlinked
to the libgdal.so.<release_version>.

The above files would be what is required of a program to run an
already compiled binary.

For building things with gdal, then you also should have a libgdal.so
file that is symlinked to the libgdal.so.<SONAME> file.

So what would this look like for a 1.2.0 release?

libgdal.so.1.2.0
libgdal.so.1 -> libgdal.so.1.2.0
libgdal.so -> libgdal.so.1

Anyway that is my understanding of it, I could be wrong.

Of course if with every release of gdal, it breaks binary
compatibility, you may be saying, doesn't the SONAME then increase to
2? does that mean you have to call it gdal 2.something? No. You may
know that libfreetype is at 6, yet the version number is only at 2.1.1
IIRC.