[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