[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DebianGIS] Re: gdal



On Mon, 2005-12-19 at 09:34 -0500, Frank Warmerdam wrote:
> 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.

Frank,

What is considered version-to-version? Is it possible to have the
expectation that the ABI will remain unchanged for 1.2.0 - 1.2.x and
then change for 1.3.0, etc.? Perhaps if ABI changes are saved for
"major" new release versions we can deal with rebuilding everything
periodically.

Steve

> 
> 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
> 
> _______________________________________________
> Pkg-grass-general mailing list
> Pkg-grass-general@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-general




Reply to: