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 gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev