[gdal-dev] Access SVN revision number from runtime?

[Roger Bivand]

On Thu, 16 Aug 2012, Even Rouault wrote:

> Selon Roger Bivand <Roger.bivand at nhh.no>:
>
>> 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
>> gdal-dev at lists.osgeo.org
>> 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: Roger.Bivand at nhh.no