On Fri, 24 Oct 2025, Javier Jimenez Shaw via gdal-dev wrote:
One breaking change for GDAL 4.0 could be to add "gdal" to the path of the
includes for external applications or libraries.
An external application should do :
#include <gdal/cpl_string.h>
instead of
#include <cpl_string.h>
That does mean that if I have multiple versions installed
they would have to be in eg
~/gdal/4.0/include/gdal/cpl_string.h
~/gdal/4.1/include/gdal/cpl_string.h
~/gdal/git/include/gdal/cpl_string.h
instead of just
~/gdal/4.0/include/cpl_string.h
~/gdal/4.1/include/cpl_string.h
~/gdal/git/include/cpl_string.h
At present a single symlink will allow external applications
to use
#include <gdal/cpl_string.h>
If we moved the header files into include/gdal
then supporting external applications that use the old scheme
could mean a symlink for each header file.
---
The people most affected by this change are probably packagers; do we
have many of those here, or would we need to ask somewhere where they
would see ?
I note that the Ubuntu (and presumably Debian) libgdal-dev package
already has its header files in /usr/include/gdal/
and the libmapserver-dev package has /usr/include/gdal in the cmake
setting: MAPSERVER_INCLUDE_DIRS
so your suggestion might be a no-op for Ubuntu developers.
[ Also true for Scientific Linux 6 (aka Red Hat 6)
- I don't know about current Red Hat, Fedora, CentOS, ... ]
in a similar way as many other libraries, like Eigen
#include <Eigen/Core>
It is really a big change for other libraries and applications, I know. But
I find useful and nice to know where are "those includes coming from" in my
application.
Cheers
Javier.
PS the same would be nice in other libraries, like libgeotiff. But I do not
expect a mayor release there.
On Ubuntu
dpkg-query -L libgeotiff-dev | egrep include
shows that this has also been done.
--
Andrew C. Aitchison Kendal, UK
[email protected]
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
