On Thu, 16 Aug 2012, Even Rouault wrote:
Selon Roger Bivand <[email protected]>:
gcore/gdal_version.h gives us the hard-wired compile-time version string.
GDALVersionInfo("--version") gives us the version known by the runtime. We
can
use GDALCheckVersion() to check that the two match (in rgdal/R). But is the
SVN
revision number exposed in the same way?
No, the revision number is not exposed in any way.
A rgdal user on OpenSUSE has reported problems writing GTiff which
turned out to stem from updates to the shared object having moved
things leading to "Failure during IO":
http://ssrebelious.blogspot.no/2012/08/rgdal-crash-solved.html. I think
that the packagers may have been rolling their updates forward,
Not sure what happened there. Sounds like some weird packaging/installation
problem against which you cannot do much.
Right, this was my basic feeling, but given the tone of his blog, I
thought I'd ask. Thanks gor responding so fast!
so I'd like to provide a more fine-grained GDALCheckVersion() which
also accesses the SVN revision. Is this possible (or sensible)?
I would advise against that. I'd go further : you should not even call
GDALCheckVersion() if RGDAL is only using the C API, which (in the GDAL
1.x series) is forward compatible. I read your comment on the above blog
that you would refuse at runtime to run against GDAL 1.9.1 if RGDAL was
compiled against GDAL 1.9.0, but I don't think you want that. You want
people to be able to install bugfixes release of GDAL without requiring
a rebuild of all packages depending on GDAL. GDALCheckVersion() is
mainly usefull for authors of plugins to detect situations where they
have compiled their plugin against GDAL 1.x and at runtime are linking
against GDAL 1.y, which for plugins using the C++ API will not
potentially work due to C++ ABI changes.
The rgdal source is part C (for proj), part C++ for OGR/GDAL, but C++
written by C-minded people, so no new classes, but using C++ OGR/GDAL
classes, things like: pDataset->~GDALDataset();. As I understand you,
1.x.a and 1.x.b share the C++ ABI, but say 1.x.b and 1.y.a will probably
not.
This suggests that I may use GDALCheckVersion(GDAL_VERSION_MAJOR,
GDAL_VERSION_MINOR, NULL); to get something that might help users debug
performance failures, but that GDAL_VERSION_REV is too fine-grained.
Best wishes,
Roger
Thanks,
Roger
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [email protected]
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
