> 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)

Will this support COMPONENTS? I would never recommend using COMPONENTS because 
it can get odd in the case of multiple calls. Will there be a 
find_package(Qt6Core) etc too?

>         (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

This is quite different to how the Qt4-to-5 transition was done. Is there any 
comparison of different approaches? Will Qt-users be able to have a single 
buildsystem with some targets linking to Qt 5 and others linking to Qt 6, as 
was possible in the 4-to-5 transition (because of the different target names)? 
As the Qt5:: prefixed names already exist those could be used in that case, but 
if there are no Qt6:: prefixed target names, then that won't be possible in Qt6 
to Qt7 transition?

Thanks,

Stephen.

From: Development <[email protected]> On Behalf Of Simon 
Hausmann
Sent: Wednesday 13 February 2019 09:33
To: [email protected]
Subject: [Development] CMake Workshop Summary

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%7C3ab1193d10204666e63408d691969a58%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856473359623333&sdata=oM%2FE0Lh%2FbCBi%2BzgKbhwssiaCrtK02zNA3hXvxX9Lcm0%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
[email protected]
https://lists.qt-project.org/listinfo/development

Reply via email to