[Development] Installing Qt5Config.cmake from the Qt repo?

Alexander Neundorf neundorf at kde.org
Thu Nov 3 20:08:55 CET 2011


On Thursday 03 November 2011, Thiago Macieira wrote:
> On Thursday, 3 de November de 2011 11:48:24 Stephen Kelly wrote:
> > No problem. If I understand you correctly, that's already the plan.
> > 
> > # Network and DBus are optional
> > find_package(Qt5 COMPONENTS Network DBus)
> > 
> > if(Qt5Network_FOUND)
> > 
> >   # ...
> > 
> > endif()
> > 
> > if(Qt5DBus_FOUND)
> > 
> >   # ...
> > 
> > endif()
> > 
> > # QtWebkit is not optional
> > qt5_add_module(mylib Webkit)
> 
> Yes! That's what I'd like to see.

Two things: 
qt5_add_module() is a bad name choice, since the add_something() commmands 
usually add a target (add_library, add_module, add_executable, 
add_custom_command, add_custom_target, kde4_add_executable, kde4_add_library, 
kde4_add_plugin, etc.).
This one is more like target_link_libraries().
I'd prefer something like target_use_libraries() or something like that.
target_use_package, target_use_framework.
Personally the "framework" term has something good, since under OSX, a 
framework combines the libs and the headers, and this is what we would do here 
too, add include directories and libraries to link against in one step.
Also, having this kind of macros makes it hard to combine Qt with other 
toolkits, which may have similar macros.
Which to use then ?
(this is the situation we are having in KDE4).

But, as I noted, this is more or less exactly what Kitware is planning to add 
anyway in the near future, so please let's coordinate with them, so we don't 
build a solution in parallel to them and end up with something similar, but 
incompatible, which we'll have to maintain:
http://public.kitware.com/pipermail/cmake/2011-November/047141.html

Alex



More information about the Development mailing list