[Development] CMake Workshop Summary

Wed Feb 13 16:23:29 CET 2019

> I think the ability to compile an application with Qt 5 or 6 and the same build system is of critical importance for the success of Qt 6.

Certainly. We had the same requirement with Qt 4+5 and had a solution for it. I'm wondering if you considered alternatives to what you're going to do and what the trade offs were.

User code will use both

find_package(Qt5)

and

find_package(Qt6)

in the same buildsystem. Having multiple packages (Qt5 and Qt6) which provide targets of the same name is sure to lead to new classes of user errors. Perhaps you need to make that an error condition?

Also, anyone providing support to users won't be able to tell whether someone using `Qt::Gui` is using Qt 5 or 6.

Anyway I suppose if you only provide `Qt::` prefixed targets now you can provide `Qt6::` prefixed targets in the future easily enough.

Thanks,

Stephen.

From: Simon Hausmann <Simon.Hausmann at qt.io>
Sent: Wednesday 13 February 2019 12:53
To: Stephen Kelly <stkelly at microsoft.com>; Vitaly Fanaskov <vitaly.fanaskov at qt.io>; development at qt-project.org
Subject: Re: [Development] CMake Workshop Summary

I think the deliberate design choice to separate Qt4 and 5 visibly in the "API" (targets) was a wise choice at that point.

For the future and with Qt 6 in mind, I think we should do it differently. I think the ability to compile an application with Qt 5 or 6 and the same build system is of critical importance for the success of Qt 6. Today's distribution of Qt versions and scale of users IMHO justifies the effort required. I think the number of people benefiting from such a design largely exceeds the users who want to use one build system to link two binaries against different major Qt versions "from within".

That is why I didn't pursue trying to modify FindQt.cmake in cmake upstream myself. I think just solving this for 5/6 would be sufficient to achieve the goal.

Simon
________________________________
From: Stephen Kelly <stkelly at microsoft.com<mailto:stkelly at microsoft.com>>
Sent: Wednesday, February 13, 2019 12:32
To: Simon Hausmann; Vitaly Fanaskov; development at qt-project.org<mailto:development at qt-project.org>
Subject: RE: [Development] CMake Workshop Summary

As a deliberate design choice years ago, we put the major version in the package name because it avoids a class of user errors and confusion, and because it allows a single buildsystem with targets linking to either Qt 4 or Qt 5 (CMake ensures that nothing attempts to link to both).

Thanks,

Stephen.

From: Development <development-bounces at qt-project.org<mailto:development-bounces at qt-project.org>> On Behalf Of Simon Hausmann
Sent: Wednesday 13 February 2019 10:47
To: Vitaly Fanaskov <vitaly.fanaskov at qt.io<mailto:vitaly.fanaskov at qt.io>>; development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] CMake Workshop Summary

That may be possible to implement. It requires the work to be done upstream in cmake's FindQt.cmake. It also requires maintaining compatibility with Qt 3 and 4. See

    https://devdocs.io/cmake~3.12/module/findqt<https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdevdocs.io%2Fcmake~3.12%2Fmodule%2Ffindqt&data=02%7C01%7Cstkelly%40microsoft.com%7C1971fe24e1f04147595108d691b22111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856591585510122&sdata=g4KhldsgBDre4UAurmyGqaWfgRKQa157%2FenJsiol40E%3D&reserved=0>

I suggest for you to get in touch with the CMake developers to see what they think about it.

Simon

________________________________

From: Development <development-bounces at qt-project.org<mailto:development-bounces at qt-project.org>> on behalf of Vitaly Fanaskov <vitaly.fanaskov at qt.io<mailto:vitaly.fanaskov at qt.io>>
Sent: Wednesday, February 13, 2019 11:22
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] CMake Workshop Summary

Hi Simon,

Thank you for the update.

It's not clear why you included version to a package name (e.g. Qt5/Qt6). With CMake you can pass a version as the second argument, e.g.: find_package(Qt 5.12)

Perhaps it would be better, what do you think?

On 2/13/19 10:33 AM, Simon Hausmann wrote:

Hi,

On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate the attempt of building Qt with CMake. I'd like to give a brief summary of this workshop.

Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and Albert.

A very early visible artifact was the creation of a wiki page (like all good workshops ;-)

    https://wiki.qt.io/CMake_Port<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.qt.io%2FCMake_Port&data=02%7C01%7Cstkelly%40microsoft.com%7C1971fe24e1f04147595108d691b22111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856591585520126&sdata=GC4pRXc4dxe%2BqeVG2zAyZtw%2FnGoaaY%2F3ca28H9LJBHQ%3D&reserved=0>

With such a large group, we were able to make good progress:

    * We were able to fix the artifacts of "make install" in qtbase to allow for building an external module (qtsvg) and sample apps. The plan for allowing people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:

        (1) In your application use either find_package(Qt5) or find_package(Qt6)

        (2) Always use Qt::Core, Qt::Gui, etc. for linkage

        (3) We want to add the "plain" Qt::Core, Qt::Gui, targets also to Qt5's cmake support

    * The script to converting .pro files to CMakeLists.txt is becoming really good. The goal is to convert all scopes and (source) file names correctly. Right now the repo contains incremental conversions with hand-edits.

    * We're working on installing the latest cmake (as required) in the provisioning setup, so that we can get a building CI as soon as possible.

    * We were able to verify that cross-compilation works well. The main challenge is ensuring that third-party libraries that used to be copied in src/3rdparty are either installed in the sysroot or can be found outside.

    * We discussed and experimented with different ways of making static builds robust. So static builds themselves work already, but what we're looking into in particular is an automatic way of propagating Qt internal dependencies (such as double-conversion) correctly to the build process of the application that is not fragile.

    * We added a lot more plugins and platform support libraries to the build process and did many improvements to the finding of external libraries.

Our overall next goal is completing the build on Linux, macOS and Windows, cross-compilation, static builds and basic CI build support.

Simon

_______________________________________________

Development mailing list

Development at qt-project.org<mailto:Development at qt-project.org>

https://lists.qt-project.org/listinfo/development<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fdevelopment&data=02%7C01%7Cstkelly%40microsoft.com%7C1971fe24e1f04147595108d691b22111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856591585520126&sdata=xn%2F%2FGuWHBj0cA5M4VkGbF1yq%2BP4LX7bOZysexHmqVvQ%3D&reserved=0>

--

Best Regards,

Fanaskov Vitaly

Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190213/02220efa/attachment.html>