Update to QT6

[TheForce172]

Goes along with scp-fs2open/fs2open.github.com#7029

[notimaginative]

Would this work with the Qt6 version in ubuntu 22.04 (qt 6.2.4)?

I'm working on updating, fixing, and optimizing the build image and will move to 22.04 with that. I can drop a layer and greatly reduce complexity if the base ubuntu packages are suitable.

[TheForce172]

Not really. 6.2 is way way out of date. And the whole point of moving to QT6 is to get us back in supported versions. Just pinning us to another outdated version not even in LTS kind of defeats the whole point of that.

I'd say the minimum version we could support would be 6.8

[notimaginative]

This is more of a general packaging question, but Is Qt dynamically linked by QtFRED?

I'm curious about whether we're going to be required to bundle Qt6 with official builds or not (assuming that's even possible). That applies to Qt5 as well obviously, but I'm updating packaging stuff for the eventual SDL3 merge and need to sort this out.

[TheForce172]

Yes. Qt5/6 dlls need to be include in the release package at least on windows. On Linux I "think" we use the users system version but don't hold me to that.

On windows/mac the copying of the dlls is done by cmake during the build process and there just added to the zip.
https://github.com/scp-fs2open/fs2open.github.com/pull/7029/files#diff-d91e2a248c82a365516548dd1a973fea7108701ce18f315bcd809676f5ae59b9 line 71 of the new code is what handles it.

[notimaginative]

Would there be an issue building with qt 6.9.2 and running with qt 6.2.4? If so then we can't rely on the system version on Linux and will have to figure out a way to bundle the libs.

[TheForce172]

I'm afraid going to have to answer here "Don't ask me I'm a windows dev". I'm afraid the linux build chain is an arcane art to me and I got this working only by banging rocks together till it worked.

Effectively for linux I took what we had for QT5 and scribbled out 5 and wrote 6. if you want to understand it you'd have to talk to the person who wrote it in the first place.

[MjnMixael]

I'm primarily a Windows dev as well but as best I can tell from The Googles Qt guarantees that an older app on newer Qt will work, but not the other way around. I would expect a binary built against 6.9.2 would fail at runtime with 6.2.4. Seems like we'll have to bundle the libs for Linux as well, then.

[notimaginative]

Okay so the plan is to target 6.9.2? If we can set that as a hard limit then I'll start working up a full set of prebuilt libs for all platforms.

I'd like to avoid having Qt (5 and/or 6) in the build image at all if possible, so how likely is it to get the port to Qt6 done by the end of April? It doesn't have to be done that soon, just trying to establish a timeline to shoot for.

We have a bit of an issue getting full Wayland support on Linux and fixing that requires syncing up multiple lib updates, in multiple PRs, across multiple projects, and having it all merged in the proper order and at the right time. Among those things I have the least amount of knowledge and experience with QtFred/Qt6 so it would help greatly to lock that down so I know exactly what I need to work on to finish all that up.

[MjnMixael]

I will defer to @TheForce172 on the timing. It's been 7 months. We probably need to verify if anything needs migration on current master when moving to Qt6 before we lock in a timeline.