Add libKML support to GDAL

[rburhum]

Removed the explicit omission of the libKML GDAL driver. The configure script of GDAL is smart enough to recognize when a valid version of libKML is available and build against it.

I am also coordinating an official release of libKML. Once that is done, I will update the relevant Formula for it to bump up the versions.

[Sharpie]

Seeing as how GDAL will only build against the trunk version of libKML, we should wait on adding it as a dependency until upstream cuts a new release.

Otherwise, we are just adding to the build time without deriving any benefit.

[rburhum]

OK, how about this? I added a head option for libKML so it can be built with

brew install --HEAD libKML

then, you can build the driver with:

brew install gdal

The change to omit "--without-libkml" is still necessary so that the normal gdal configure script picks up the now valid libkml library.

[Sharpie]

The change to omit "--without-libkml" is still necessary

That change is not consistant with how the formula handles configuration options. All additional drivers, including things like NetCDF, are disabled unless the --complete option is used.

If you want to enable libKML, install it from HEAD and then build GDAL with the --complete flag and it should get picked up.

[rburhum]

I noticed that was the behavior. May I ask why?

Doing a GDAL complete brings in several extra dependencies, so your build time increases by a lot (makes sense).

But, IMHO, explicitly removing libKML doesn't make sense in any scenario.

If you have it installed from head, your build time will increase by a few seconds and the driver will be built. If you don't have it installed (or have the current 1.2 version defined in the brew), the gdal built system will omit it and your build time is affected by nothing.

IMHO, the complete flag is useful to avoid bringing in extra dependencies, but once they are there, explicitly avoiding them is not too useful unless you are talking about bringing in things like grass.

[Sharpie]

but once they are there, explicitly avoiding them is not too useful

Unless they are broken. Explicitly disabling everything not provided by Homebrew keeps the GDAL build stable and ensures brew install gdal has a high probability of success even in the presence of broken libraries or libraries that were built in a foreign environment such as MacPorts or William Kyngesburye's builds.

The --complete option opens a backdoor to this policy as a side effect---really there should be a seperate --enable-unsupported-drivers option for things like MrSID, dwgdirect, libKML HEAD, etc.

[rburhum]

Let me know if that works for you.

[rburhum]

By the way, I fixed another bug you had submitted http://trac.osgeo.org/gdal/ticket/4630 on trunk, After the next release, we should be able to take the patch section of gdal.rb

[Sharpie]

Allright. Pulled as part of some long overdue GDAL cleanups.

Now, passing the --enable-unsupported flag to brew install gdal will allow configure to enable any libraries it finds floating around in the environment instead of having this behavior be a side effect of the --complete flag.

And thanks a bunch for getting a fix for the libdap test in upstream!

[rburhum]

Hey, no problem! Thanks for adding --enable-unsupported. By the way, what is the accepted Homebrew way of adding support for packages that contain proprietary binaries? I want to be able to add support for FileGDB which relies on the installation of a proprietary SDK.

Here is a description of how I do it right now:

http://blog.burhum.com/post/34851795066/installing-gdal-ogr-with-filegdb-support-on-osx-with

[Sharpie]

By the way, what is the accepted Homebrew way of adding support for packages that contain proprietary binaries?

Well, it all depends on whether or not the binary/source can be redistributed. If it can, then there shouldn't be a problem with us parking it somewhere outside of the login wall and making it publicly available.

If it can't, then the best approach is a custom download strategy that requires the user to somehow obtain the source or binary package and put it in the Homebrew download cache (see the output of brew --cache).

An example can be found in a formula I wrote for ADCIRC which is a proprietary model for hydrodynamics simulations:

https://github.com/Sharpie/homebrew-science/blob/master/non-free/adcirc.rb#L3-24

You could maintain these formula in a repository, say homebrew-gdal_nonfree, and users could add them to their Homebrew installation using brew tap RBURHAM/gdal_nonfree.

[rburhum]

Great. Thank you again!