> 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.


Spatialys - Geospatial professional services
gdal-dev mailing list

Reply via email to