Porting to Qt 6 - switch to cmake first?

Bob64

We have a fairly mature QML application that was originally developed mainly using Qt 5.9 and later upgraded to 5.15. Within the next year or so, my company will require those of us using Qt to have moved to Qt 6 and I'd like to get a head start on this.

We are currently using qmake but I understand the default build system in Qt 6 is now cmake and it seems that it might be a good time to make the switch. One thing I'd like to get advice on is whether it would make sense to make the switch while in Qt 5 and then do the port, or would there be anything wrong with continuing with qmake until the port is complete? Are there any factors that might make one or other approach better?

The port of the code itself could be quite complicated because we rely heavily on TreeView, which in Qt 5 is obviously the Controls 1 component that was removed in Qt 6. Although a new TreeView has subsequently been introduced in Qt 6, it's not a drop-in replacement. Therefore to bootstrap a port to Qt 6 we will probably have to rip out a lot of functionality and reimplement/add it back in. Because of this, I am tempted to focus on the code changes first and stick with qmake for now, and switch to cmake later. But am interested to hear if anyone would recommend that I make the build system switch first while still in Qt 5.

SGaist

Hi,

Is your qmake project complex ?
If not, then switching to cmake might simply be the easiest thing to do first.
You'll have the build system in place and then ready to benefit from the new features introduced through Qt 6.

To do an initial evaluation of the port work, there's a helper script somewhere in qtbase IIRC that might help you. It was used to bootstrap the migration of the Qt modules. It's not able to handle all the corner cases but might be enough already for your project.

Bob64

@SGaist said in Porting to Qt 6 - switch to cmake first?:
Thanks for your insights. I'll look for the script you mentioned.

Is your qmake project complex ?

I don't think so. I think the basic structure is straightforward. The main potential complication is that we depend on some external libraries that are located via environment variables, and a bit of manipulation is done on the paths. I only have very rudimentary exposure to cmake so I don't have a feel at this point for what may or may not be complicated.

I've outlined the qmake project below anyway. I'd be grateful if you can spot anything that might cause any complication.

myproj.pro
----------
  TEMPLATE = subdirs
  SUBDIRS += app chartapp core tests
  app.depends = core
  chartapp.depends = core
  tests.depends = core

app.pro
-------
  TEMPLATE = app
  # main application executable (QML GUI)
  # builds some "main" source and links "core" static lib
  RESOURCES += qml.qrc
  win32:RC_ICONS = <app icon>

  # Some addition of external libs via LIBS += ...
  # - Only in linux case
  # - Involves manipulation of some env vars to find them:
  #   we use $$clean_path, $$getenv and $$split

chartapp.pro
------------  
  TEMPLATE = app
  # another QML GUI executable - builds an interactive testing app for our charting component
  #  depends on the common "core" lib that the main application uses.
  # has own 'main' source 
  # has own qml.qrc, but most qml is shared with "app" by using relative paths into the app area   

core.pro
--------
  TEMPLATE = lib
  # static lib with all C++ backend code
  
  # INCLUDEPATH appended to for external libs, again involves some env var manipulation

tests.pro
---------
  TEMPLATE = subdirs
  # usual thing with a subdirectory/project/test class for each test suite

Bob64

Regarding the conversion script I found qmake2cmake (see here for info) but it requires a Qt version of at least 6.0.0 to work. I don't think this is an option.

I either need to port the code to Qt 6 while continuing to build with qmake and then switch to cmake once everything is building and running, or convert to cmake while still in Qt 5 and then port to Qt 6.

JonB

@Bob64
FWIW I did the move from Qt5 to 6 and from qmake to cmake at the same time, as they seemed to go hand in hand! But I did not have large, complex projects to convert, I can understand you may not want to do both in one go.

I think either one first is OK. My initial inclination might be cmake first then Qt6, as I have a feeling there will be more work for the latter than for the former. And it might be nice to start moving from Qt5 to Qt6 knowing that you made the existing, working code under cmake. However if you have complex builds and you really feel this qmake2cmake would help the conversion process that might be a reason to get going with Qt6 first so that you can use it.

In any case I have a feeling you will want to install Qt6 side-by-side with your existing Qt5 rather than overwriting it, as you will doubtless want to refer/test/play with working code under Qt5 for quite a while as you separately transfer over to Qt6. So you should be able to get qmake2cmake going as soon as you have a Qt6 installed. Unless you mean that it can only work on qmake/cmake files for Qt6.x projects, not that it needs Qt6 itself to run.

Bob64

@JonB said in Porting to Qt 6 - switch to cmake first?:

Thanks Jon. So another vote for early migration to cmake.

Unless you mean that it can only work on qmake/cmake files for Qt6.x projects, not that it needs Qt6 itself to run.

Yes unfortunately that is what I meant. It is a Python script that is pip installed independently of any Qt installation. You have to specify the minimum Qt version as a command line option, but it won't accept anything less than 6.0.

Anyway, I already have both Qts installed side by side and I have started a new git branch in which I am making changes.

The good news is that the C++ code all compiles without a hitch in Qt 6 (still using qmake at this point).

My plan now is to identify any incompatibilities in the QML that I can deal with (i.e. not including TreeView) in Qt 5. This includes a couple of uses of the Controls 1 SplitView and dialogs from QtQuick.Dialogs 1.2. A new SplitView was introduced after 5.9 that we hadn't got around to migrating to, so that should be OK. I think I can deal with the dialogs by switching to the Qt.labs.platform versions for now, as they seem to be pretty much the same between Qt 5 and 6. (Once everything else is working and I am more fully migrated to Qt 6 I can look then at moving to the new QtQuick.Dialogs in 6.x.)

Once I have done this I will replace the TreeView with some sort of placeholder to try to bootstrap an app that builds and runs (after a fashion) in Qt 6, still built with qmake. Once I have that I should be able to use the qmake2cmake script to migrate the builds before I continue with the port.

SGaist

Sounds like a plan !
Good luck :-)