Re: [DebianGIS] Re: gdal
On 12/19/05, F.Sluiter <fsluiter@gmail.com> wrote:
> Folks,
>
> > Am I missing an alternative solution?
> A separate solution (more like a hack) could be to rename the library to
> qgis-gdal and package that together with qgis, however there are more
> then likely more packages that are affected by an API change of gdal.
>
> Just a dumb question:
> But is there a sound reason for the C++ API to break? Why can't it be
> backwards compatible (as I understand is the C-API)? I fully
> understand that this potentially creates unsolvable development
> problems, however:
Floris,
In order to preserve the C++ ABI it is necessary to be very
rigerous about how the C++ classes evolve. For instance, as
long as client code is calling "new" to create library objects, it
is absolutely necessary that none of the impacted classes
change in size or internal layout in any way. New methods
have to be added very carefully to avoid perturbing the vtable
layout.
There are models for doing this, but GDAL does not follow
them.
> It sounds somewhat strange to offer a changed C++API to a library
> without changing the library major version number.
> Especially considering Franks statement:
> > The C++ API is the "real" API. The C API is a set of cover functions.
>
> Or am I now missing something?
> IMVeryHO breaking an API needs some consideration on who it might
> affect and if it might be avoided if at all possible. Making an API
> available does give users hope and expectations on using the library.
Note we are talking about changing the ABI (the binary interface).
The API is quite backward compatible, but because the ABI changes
recompilation against the newer GDAL is required.
> So <perhaps> a better solution: create/keep a backwards compatible
> C++-API, and/or keep that API as compatible as possible and updating
> the lib version when it is not.
No offence, but this it the tail wagging the dog. It is a given that the
GDAL C++ ABI is unstable from version to version. I have long privately
advised applications to use the C API if they want to be reasonably
decoupled from the underlying GDAL as is valuable in packaging
situations like Debian.
I would note that MapServer also uses the C++ OGR API and
will have similar problems. While it has been my intention to
correct this in MapServer for some time, it is complicated by the
use of certain C++ only "style" related classes.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
Reply to: