[gdal-dev] installed header files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] installed header files

Ari Jolma-2
In 2.3 the installed header files is limited to a fixed list. That is a
good thing. Even better would be to install the header files into a GDAL
specific subdir.

However, that change broke one thing: the bindings cannot now be built
against the public header files. At least cpl_vsi_error.h is needed(1).

But, I'm wondering should the bindings be separately buildable anyway.
The bindings are pretty much married to the specific version of the
source tree.

The case above is a CI run where I'm building the Perl bindings
separately with the help of another Perl module (Alien::gdal), which
does the actual download-build workflow for GDAL. The reason for this is
to have the GDAL Perl bindings in CPAN as a stand-alone and testable
module. That's a good reason, however, I'm moving to recommending using
the FFI based module (Geo-GDAL-FFI), which is more robust and doesn't
need the header files to install and run.

Ari

(1) https://api.travis-ci.org/v3/job/380159862/log.txt


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: installed header files

Even Rouault-2

Ari,

 

> In 2.3 the installed header files is limited to a fixed list. That is a

> good thing. Even better would be to install the header files into a GDAL

> specific subdir.

>

> However, that change broke one thing: the bindings cannot now be built

> against the public header files. At least cpl_vsi_error.h is needed(1).

 

This is an oversight. I've just fixed it.

 

>

> But, I'm wondering should the bindings be separately buildable anyway.

> The bindings are pretty much married to the specific version of the

> source tree.

 

The bindings at a version X will generally require at least a version of the GDAL lib that is equal or more recent than X.

 

>

> The case above is a CI run where I'm building the Perl bindings

> separately with the help of another Perl module (Alien::gdal), which

> does the actual download-build workflow for GDAL. The reason for this is

> to have the GDAL Perl bindings in CPAN as a stand-alone and testable

> module. That's a good reason, however, I'm moving to recommending using

> the FFI based module (Geo-GDAL-FFI), which is more robust and doesn't

> need the header files to install and run.

 

Potential drawback I see: if/when the GDAL C API will change, that's probably make it harder to spot places where changes should be made in the signatures.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev