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

Matt Williams lists at milliams.com
Fri Oct 28 16:24:08 CEST 2011


On 28 October 2011 14:44,  <lars.knoll at nokia.com> wrote:
> Hi Stephen,
>
> On 10/28/11 1:13 PM, "ext Stephen Kelly" <stephen.kelly at kdab.com> wrote:
>
>>
>>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.
>
> I think that's reasonable in general. It's similar to what we do to
> support pkgconfig. I agree with Thiago's comment that this should be split
> and we should have one file per shared library.

I think Stephen's suggestion of having one CMake file for all Qt
Essentials using find_package(Qt5 COMPONENTS QtGui etc...) makes the
most sense, at least for specifying which QtEssential libraries to
build against. It is the way most CMake files like this are done and
is not dissimilar to how the existing FindQt4.cmake works. Whether we
have a separate CMake file for Qt Addons (whether a separate one for
each module of another combined one) becomes a separate issue.

> How is this dependency wise? Would we need to install these files into a
> special location and how do we know where this location is? Does
> supporting the feature require cmake to be installed?

>From http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_package
(page down a little) you have a number of options of where to install
them. For example <prefix>/(share|lib)/<name>*/(cmake|CMake)/ where
<prefix> could be /usr and <name> could be 'Qt5' so they could be
installed in /usr/share/Qt5/cmake. There's similar special paths on
Windows and Mac.

For the purpose of building and installing Qt we have no dependence on
CMake. As Stephen says the files could just be created from some
templates using a bit of Perl (or whatever you want). For someone
building a project which depends on Qt they would of course need CMake
to find these files.

-- 
Matt Williams
http://milliams.com



More information about the Development mailing list