Code and API review request for Qt5 CMake files

[Stephen Kelly]

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.kelly at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120224/8e4816ce/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120224/8e4816ce/attachment-0001.p7s>