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

[Stephen Kelly]

Hi,

== Summary ==

I'm considering adding some cmake files to Qt, which would be installed by Qt, 
and which would make it easier for CMake based projects to depend on Qt.

I'm CC'ing the cmake developers too see what they think of the idea too.

== Clarification ==

To avoid misunderstanding:

* This proposal is not about porting the Qt build system to CMake.
* This would not make Qt depend on CMake at all
* I am proposing to add some plain text files to the Qt repo for installation
* Those plain text files would need to be generated while building Qt (using 
existing mechanisms, like perl).

== How CMake finds packages ==

(Skip this section if you already know how CMake finds packages)

For those who have not used CMake before, it has two ways to find dependencies:

* If you want to find a dependency, you write a Find<Package>.cmake file or use 
    an existing one. Usually this Find<Package>.cmake will not be installed.

* If you want to be easily found for others to depend on, you write a 
    <Package>Config.cmake file and install it to a location CMake will use to  
    find things like that. I assume this is similar to how pkgconfig works, but 
    I have never used pkgconfig. 

    This is most common in the case of projects which use CMake themselves, 
    but there's no reason projects which do not use CMake can't provide 
    similar files. This becomes even more useful with recent CMake features 
    based on finding packages.

Either way, if someone does this in CMake:

find_package(Package)

the result is the ability to use the headers and libraries from Package.

CMake ships with FindQt4.cmake, so anyone using CMake uses 

find_package(Qt4)

to be able to use Qt 4.

== Qt5Config.cmake ==

I propose that we ship a Qt5Config.cmake file with Qt which we install, along 
with macros equivalent to what is currently in Qt4Macros.cmake, and some 
Targets.cmake files.

Then find_package(Qt5) in CMake would use that Config file and there would be no 
need for a FindQt5.cmake.

The advantage of this are:

* It allows people using CMake to start experimenting with Qt 5 ports sooner
* When new features arrive in Qt (such as new libraries like QtDeclarative was 
in Qt 4) we can update the Qt5Config file immediately and test the new features 
more easily.
* We can use the cmake imported targets feature to more easily support debug 
and release versions on Windows.
* KDE does not need a separate FindQt.cmake to the one shipped by CMake.

== Maintainance ==

KDAB (specifically myself) can maintain these CMakes files. We have other 
engineers with both Qt and CMake competencies, and there are more people in 
the CMake and KDE communities with cross-competencies.

That is assuming it works of course. I haven't even prototyped yet in case 
there is some reason this shouldn't be done. I'm quite confident it will 
work though.



I can't think of any reason this effort should be prevented, but if you have a 
reason, please let me know. I'm looking for early objections before I start to 
do any work.

Thanks,

-- 
Stephen Kelly <stephen 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111028/4fb0cbb7/attachment.bin>