Am 24.10.25 um 15:08 schrieb Andrew C Aitchison via gdal-dev:
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
AFAICS the original proposal doesn't imply a particular prefix.
There could also be
/usr/include/gdal3/cpl_string.h
/usr/include/gdal4.0/gdal/cpl_string.h
Compare with libxml2:
/usr/include/libxml2/libxml/uri.h
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.
It is not so easy, see my example. If you don't want to allow gdal to
add /usr/include (or similar top-level prefixes) to the search path, you
must still add another subdir.
Are there particular GDAL include files which are prone to name clashes?
Kai.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
