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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev