[gdal-dev] Regarding libkml driver

Even Rouault even.rouault at spatialys.com
Thu Aug 20 07:48:13 PDT 2015


On Thursday 20 August 2015 13:46:52 Sebastiaan Couwenberg wrote:
> On 02-08-15 21:05, Even Rouault wrote:
> > On 02-08-15 20:45, Rashad M wrote:
> >> No API changes. it make building and configuring libkml easier!
> >> 
> >> Correct me If I am wrong, I guess with a pkg-config would be easier to
> >> find
> >> and configure libkml libs.
> > 
> > Yes, that would probably be better. That said my experience with GDAL
> > configure --with-libkml has been good up to now. But having a pkg-config
> > script could simplify the current detection and configuration logic.
> 
> The current m4/ax_lib_libkml.m4 doesn't detect the new libkml because it
> still expects the thirdparty boost headers.
> 
> We should probably keep this as a fallback for the old libkml, but
> prefer pkgconfig if that's available as is the case for the new libkml.

Sounds good to me. 

> 
> As part of the ongoing GCC 5 transitions we've switched to the new
> libkml in Debian, with the geos & gdal transitions soon to follow, and
> gdal now builds without KML support because it doesn't detect the new
> libkml properly.
> 
> I'm working on a patch to try and support both the old Automake based &
> new CMake based libkml by adding support for libkml.pc.

Are there differences in the installed files from libkml whether you use 
automake or cmake ? Or did you mean that you're attempting to remove those 
differences ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list