[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