Hi there, Qt5 generates its own CMake files, which you will be able to use to find Qt5 and build with it.
That is, you will port from, eg
find_package(Qt4 REQUIRED Core Gui Xml)
to
find_package(Qt5Widgets REQUIRED)
find_package(Qt5Xml REQUIRED)
find_package(Qt5Core) is also possible but is not needed because it is a
dependency of at least one of the other requirements already in this case.
find_package(Qt5) will not work currently (though it can be made to work now
or after Qt 5.0).
You will then port
target_link_libraries(foo ${QT_QTCORE_LIBRARIES})
to
target_link_libraries(foo ${Qt5Core_LIBRARIES})
etc.
Or you might use qt5_use_package:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3083
qt5_use_package(foo Core)
# That's it! Nothing more to do.
The variables all map fairly well. There is also a Qt5Transitional package
which might help with that (If it gets released, which I'm not certain it will
be): https://projects.kde.org/projects/kdesupport/extra-cmake-
modules/repository/revisions/master/entry/modules/FindQt5Transitional.cmake
The Qt5<module>Config.cmake files are generated and installed by Qt itself.
I'd like a review of them by people familiar enough with how CMake works and
an API review from people familiar with how it is used.
The generation of them is platform specific, and configure options specific,
eg whether you use -framework on mac, whether you use MinGW or MSVC, whether
building with an infix or a namespace. The easiest way for you to generate the
config files is:
# Note: Don't bother cloning qt5.git unless you already have it.
# That takes forever.
git clone git://gitorious.org/qt/qtbase.git
cd qtbase
./configure
ls lib/cmake
Make sure you have at least commit c470999329ee576038c50573314699f972f48909.
You can go on to build and test them if you wish. The ctest unit tests are in
qtbase/tests/manual/cmake. These tests are not part of any multi-platform CI
system.
Compared to the last time I emailed about this, the generated Config files
have become more simple. I discovered that qmake can have conditionals in its
configure_file equivalent.
Things that work:
* Finding Qt with an infix.
* Building against Qt with a namespace.
* Finding statically built Qt (though when linking you have to list the
dependencies yourself currently)
* Finding a particular version should work as ConfigVersion files are
installed, but I have not tested it.
Things to review:
* Are the Config files created correctly for your platform and configuration?
* Do the unit tests pass on your platform?
* Currently there is no Qt5Config.cmake.
Such a thing could probably exist and use the FIND_COMPONENTS to find what was
requested. However, because there is no way to signal from a Config file that
a component was not found (that is, find_package(Qt5 REQUIRED Gui Xml) might
not find QtXml, but Qt5_FOUND would still be true if the Qt5Config file is
found, whether the component is or not), I'm not sure it's a good idea, or at
least it's more complicated. At least, I think something like qt5_use_package
is a better idea anyway.
We could have a small FindQt5.cmake in CMake which could do that however
maybe.
* Do you see any issues related to cross compiling?
* Try my port of the CMake Gui dialog to Qt5, or review the patches (most of
the patches make sense in CMake master anyway IMO):
https://gitorious.org/~steveire/cmake/steveires-cmake/commits/qt5-port
* API Review -
Do the variable names make sense? For example, to find a regular Qt5Gui, you
use find_package(Qt5Gui) and then you can use ${Qt5Gui_LIBRARIES}.
To find a Qt which was built with a namespace you use find_package(Qt5Gui) and
then you can use ${Qt5Gui_LIBRARIES}. That is - it's exactly the same.
To find a Qt that was built with an infix in the library names, you use
find_package(Qt5Gui) and then you can use ${Qt5Gui_LIBRARIES}. That is - it's
exactly the same.
Is there any reason for it not to be the exact same in all these cases?
I'd imagine if using an infix-ed Qt, that's an implementation detail. If using
a namespaced Qt, it might be an uninteresting implementation detail. I'm not
really certain of the use-cases for a namespaced Qt and how that might affect
this CMake API.
* Is anything missing? One thing that is missing is the qt4_automoc macro (all
other macros are available with qt5 equivalents). Alex say's it's broken. The
CMAKE_AUTOMOC feature is a not-completely-source-compatible replacement.
Thanks,
--
Stephen Kelly <stephen.ke...@kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
smime.p7s
Description: S/MIME cryptographic signature
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
