[gdal-dev] Regarding libkml driver

[Sebastiaan Couwenberg]

On 20-08-15 16:48, Even Rouault wrote:
> On Thursday 20 August 2015 13:46:52 Sebastiaan Couwenberg wrote:
>> 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 ?

Both are significant changes between the old and new libkml upstreams.

The old libkml that originated on code.google.com, and is now maintained
on github.com/google/libkml, uses Automake to build the libraries and
swig bindings. It relies on embedded copies of 3rd party libraries.

The new libkml that forked from code.google.com, and is now maintained
on github.com/libkml/libkml, uses CMake to build the libraries and swig
bindings. It prefers system installed copies of the 3rd party libraries,
but can also download the required versions to use during the build.

The changes for the third_party code in libkml/libkml fork is one of it
strong points. The switch from Automake to CMake also helped get rid of
patches required to keep Automake working with recent versions.

With the renewed activity around google/libkml with the new engineers
joining the project, I'm hopefull we can get the libkml/libkml changes
back into google/libkml. If libkml development remains active in
google/libkml the libkml/libkml fork won't be required anymore.

Until google/libkml becomes a viable alternative to libkml/libkml, I'm
using the latter as upstream for the libkml Debian package that is
primarily required for gdal.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1