[gdal-dev] report proj4 version to which gdal is linked?

[Roger Bivand]

On Fri, 24 Nov 2017, Even Rouault wrote:

> On vendredi 24 novembre 2017 02:37:11 CET Roger Bivand wrote:
>> I've looked in ogr/ogrct.cpp, but cannot see that the proj4 version that is
>> detected internally is exposed for reporting through a function in the API.
>> It would be convenient if GDAL could report versions of some of its
>> dependencies. Checks for GDAL built with or without GEOS are now in R sf and
>> rgdal packages, because some drivers behave differently if GDAL was built
>> with or without GEOS (but not the GEOS version, which may matter for static
>> builds), We'd like to report the proj4 version used to build GDAL too, and
>> would value advice. This will become critical shortly, with the forthcoming
>> release of proj4 5.0.0, which uses a different API. There is going to be a
>> lot of muddle, so being able to check will be helpful for many.
>
> There are 2 different notions :
> - the proj version used at compile time
> - the proj version used at link time
>
> proj 4.X only offers the PJ_VERSION macro, so you can only detect the 
> compile time version.

In rgdal, we use:

#include <proj_api.h>

SEXP
PROJ4VersionInfo(void) {
     SEXP ans;

     PROTECT(ans=NEW_LIST(2));
     SET_VECTOR_ELT(ans, 0, NEW_CHARACTER(1));
     SET_VECTOR_ELT(ans, 1, NEW_INTEGER(1));
     SET_STRING_ELT(VECTOR_ELT(ans, 0), 0,
         COPY_TO_USER_STRING(pj_get_release()));
     INTEGER_POINTER(VECTOR_ELT(ans, 1))[0] = PJ_VERSION;

     UNPROTECT(1);

     return(ans);
}

to get both the declaration in proj_api.h and the one in pj_release.c 
(because they have differed). I would have (perhaps) hoped that 
pj_release.c is the runtime version, but mileage may vary ...

>
> GDAL has currently 2 modes to support proj:
> - classic mode where you build against proj headers and link the GDAL 
> shared object against the proj shared object at build time. In that 
> mode, currently,we could potentially report PJ_VERSION

That would help.

> - full dynamic mode where there's no build requirement and at runtime 
> you dlopen proj. In that mode, currently, it is really hard to know 
> which proj version we end up linking against (you can make some guess 
> depending on which symbols are available...)
>

or maybe create a pointer to pj_get_release()?

> proj 5 will have compile time PROJ_VERSION_ macros, and a proj_info() 
> function giving the version at runtime.
>
> A few months before, I proposed to drop the support for the "full 
> dynamic mode" as it makes code messy. This didn't make concensus at that 
> time, so I dropped the ball for now. But for proj 5 support, I think we 
> really need to get rid of the full dynamic mode.
>
> If proj 5 still supports the old proj_api.h (which seems to be the 
> direction), as soon as it will be released, we could probably make proj 
> 5 the minimum version for a proj-enabled GDAL build (since other 
> components of the ecosystem depending on proj 4 API will still work), so 
> as to avoid supporting 2 different APIs. Well, maybe this is a bold 
> move, and perhaps still supporting proj 4 classic mode will not be that 
> hard, but I definitly don't want to have to support "proj 4 classic 
> mode" + "proj 4 full dynamic mode" + "proj 5 classic mode".

Yes, too many modes is misuse of limited time, and the speed of (overdue 
?) changes in proj4 suggests that this is wise, also in relation to the 
downstream applications and packaging communities. It would be unfortunate 
if major platforms remained stuck with poorly supported versions of proj4.

>
>> Should I file a trac request?
>
> You may

Thanks, I'll see what I can do with this.

Roger

>
> Even
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en