[gdal-dev] Suggestion for GDAL 4.0

[Kai Pastor, DG0YT]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251025/d63ba059/attachment.htm>