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. > 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. > > Thanks, > > Roger > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
