[Kde-bindings] [PATCH] [CMake] Smoke - flexible handling of what to build and what not to

[Arno Rehn]

On Sunday 09 May 2010 07:39:46 Maciej Mrozowski wrote:
> My initial problem was to allow not building some SMOKE bindings (like
> QtMultimedia, QtWebkit and such which now are mandatory dependencies), then
> I've decided to come up with something to reduce copy&paste in toplevel
> Smoke CMakeLists.txt and possible increase manageability.
> 
> Changes:
> - introduce macro smoke_add_bindings(<var> <name> <subdir1> [subdir2 ...])
> - it's basically a little smarter version of
> macro_optional_add_subdirectory In this macro, I've also added CMake
> option to disable particular bindings (DISABLE_SMOKE_<sth> is more correct
> than ENABLE_SMOKE_<sth> because with the latter one cannot really assure
> than all satisfied deps are found, and disabling always works)
> - use macro instead of set(SMOKE_ENABLED... ) and add_subdirectory(...)
I'd rather not have this configurable. It just clutters the cmake variable 
cache for stuff that should be auto-detected. We should check whether 
QtMultimedia or QtWebKit are available, true, but please don't add an option 
to enable or disable a specific smoke module. We would have to do the same for 
QtRuby and Qyoto then and with ca. 40 smoke libs + 2*40 matching bindings we 
end up with 120 additional variables that nearly no-one ever modifies and mess 
up UIs like cmake-gui or ccmake.
If a package is there, we build smoke libs for it. Period. If you don't want a 
certain package, use -DWITH_akonadi=FALSE  (or similar) to disable ALL 
bindings for it. This doesn't allow for as much fine-tuning as your solution, 
yes, but it's sufficient for nearly all situations.

But please go ahead and make a patch that checks for Qt modules being there 
before adding the bindings. We'll need that anyway when we later port to 
Windows, where e.g. QtDBus is not available.

-- 
Arno Rehn
arno at arnorehn.de