RFC: Migrate from Qt5 to Qt6's Qt5 compat

dongcarl commented at 5:23 pm on December 11, 2020: contributor

It seems like migrating to Qt6 is a win for multiple efforts, and I want us to evaluate switching to it as an alternative to monkey-patching Qt5/qmake to make it work properly.

First class support for Apple Silicon for #20371 (see: https://bugreports.qt.io/browse/QTBUG-85279)
Transition from qmake to cmake (see: https://www.qt.io/blog/qt-6-build-system)
1. We already use cmake in depends to build several other tools
2. cmake is much better maintained than qmake
3. This might make a native/build split possible for qt, the last holdout package of native/build mixing after boost was recently split
4. For PRs like #20600, where we’re trying to work around qmake’s jankiness, I don’t want people to pour their heart and soul into making qmake work just to be completely replaced by cmake when we bump in the future

Supposedly, the switching cost is also minimal, as there’s a Qt5Compat module (see: https://www.qt.io/blog/porting-from-qt-5-to-qt-6-using-qt5compat-library)

dongcarl added the label Build system on Dec 11, 2020

MarcoFalke commented at 5:29 pm on December 11, 2020: member

How is this going to affect our user? According to the qt blog:

Qt has always been a cross-platform, and that will continue in Qt 6. Qt 6.0 supports

Windows 10
macOS 10.14 and newer
Linux (Ubuntu 20.04, CentOS 8.1, OpenSuSE 15.1)
iOS 13 or newer
Android (API level 23 or newer)

Are these build requirements or runtime requirements?

MarcoFalke added the label Brainstorming on Dec 11, 2020

promag commented at 10:19 pm on December 11, 2020: member

Are you suggesting to use Qt6 for depends but still use Qt5 as minimum supported? Or suggesting to bump minimum supported to Qt6?

I don’t think Qt5Compat matters that much? We can easily update the code if we are affected by those breaking changes.

I think #20600 is not the way to go, as already discussed with @hebasto, @icota and @BlockMechanic. I’m actually working (I suck at build stuff) on reverting to single archive in qt depends (requires an additional patch for 5.9.8) and simplifies adding qtdeclarative and qtquickcontrols2 modules (remaining modules are skipped ofc) or even qtmultimedia in the future for qrcode scanning.

Also worth mentioning that Qt6 requires C++17, which we already enabled for next version (#20413).

BlockMechanic commented at 0:58 am on December 12, 2020: contributor

Seems a lot of QT modules are still being adapted/fixed. The earliest estimate for a complete release is stated as 6.2.0 including all submodules. I agree with an eventual move to Qt6, however i think it’s still a bit of a ways off. I have a branch that i was adapting to Qt 6.0.0, there are quite a few patches required.

dongcarl commented at 10:11 pm on December 16, 2020: contributor

How is this going to affect our user?

From my reading, these aren’t necessary requirements but are “blessed configurations” which are the most well-tested by their CI and testing. I do agree that we need more testing for the edge cases of our supported configurations though.

I have a branch that i was adapting to Qt 6.0.0, there are quite a few patches required.

Oh very cool! Please do post on this thread if you ever push it up :-)

fanquake commented at 5:15 am on December 17, 2020: member

I think dropping support for < Windows 10 is too aggressive for us to be building releases with Qt6. We should at least wait and see if there are significant complaints (due to #18956) with the release of 0.21. I’d like to think there are already very few XP / Vista users left, however Windows 7 only stopped receiving security updates at the start of this year.

jonasschnelli commented at 5:25 am on December 17, 2020: contributor

I guess adding support for Qt6 builds (along with Qt5) is for sure a good thing. The main questions are if we should use Qt6 for depends/releases. Would it be possible and would it make sense to use Qt6 for macOS and keep Qt5 for the rest?

fanquake commented at 5:34 am on December 17, 2020: member

The main questions are if we should use Qt6 for depends/releases.

No, not yet. For at least the reason I outlined above. That would also, as far as I can see, drop support for Ubuntu 18.04LTS, which is supported until 2023. It’d also make sense to wait for at least a point release or two before we fully commit to 6.x. I think using 5.15.x for the 22.0 release is the way to move forward for now.

jonasschnelli commented at 5:41 am on December 17, 2020: contributor

No, not yet. For at least the reason I outlined above. That would also, as far as I can see, drop support for Ubuntu 18.04LTS, which is supported until 2023. It’d also make sense to wait for at least a point release or two before we fully commit to 6.x. I think using 5.15.x for the 22.0 release is the way to move forward for now.

I completely agree. Though for macOS where 10.14 is our minimum (AFAIK), we could bump to Qt6 and also make it better support macOS Big Sur 10.16

sipa commented at 7:21 am on December 17, 2020: member

If it’s easy to have source code compatible with both, there wouldn’t be much of an issue with using Qt5 in depends for Linux/Windows builds, and Qt6 for MacOS builds (or even just ARM MacOS builds).

luke-jr commented at 7:24 pm on December 20, 2020: member

This might make a native/build split possible for qt

Just a note that it was always possible - embedded Qt systems have been doing it for a long time.

drewpotter commented at 3:33 pm on January 10, 2021: none

I am not sure how accurate this article is, but it claims that Qt LTS releases will be commercial only. I am not sure if this might be an issue? I just wanted to make people aware of this. Hopefully something positive can come from using Qt moving forwards. I have used Qt for many projects, so it would be a shame if that would be the end.

The Register: Open-source contributors say they’ll pull out of Qt as LTS release goes commercial-only

BlockMechanic commented at 3:41 pm on January 10, 2021: contributor

This has the potential to be a game changer. They could lose a lot of contributors and users.

drewpotter commented at 3:54 pm on January 10, 2021: none

@BlockMechanic there has been some talk online about forking Qt. However, that would be a very serious and time consuming endeavour. Of course it’s a real shame if that would be a pathway which the community would have to choose. I am not sure what the best path would be going forwards, but I truly hope that sharing this information will help the Bitcoin community.

fanquake commented at 5:27 am on April 1, 2021: member

One thing to note is that beginning with Qt 6, Qt is also no longer providing pkg-config files: https://bugreports.qt.io/browse/QTBUG-86080.

BlockMechanic commented at 8:58 pm on May 31, 2021: contributor

Checking in, 6.1.0 is out but still no resolution for the pkg-config issue.

prusnak commented at 2:32 pm on November 12, 2021: contributor

Qt 6.2.0 LTS was released https://www.qt.io/blog/qt-6.2-lts-released

hebasto commented at 2:35 pm on November 12, 2021: member

I think using 5.15.x for the 22.0 release is the way to move forward for now.

Agree. See #23489.

fanquake commented at 8:51 am on March 25, 2022: member

Looks like pkg-config support will return as of Qt 6.4.0: https://bugreports.qt.io/browse/QTBUG-86080/

Also note that recently an open source, non-commercial Qt 5.15.3 has been released: https://lists.qt-project.org/pipermail/development/2022-March/042262.html.

prusnak commented at 9:38 am on March 25, 2022: contributor

Also note that recently an open source, non-commercial Qt 5.15.3 has been released: https://lists.qt-project.org/pipermail/development/2022-March/042262.html.

PR in https://github.com/bitcoin/bitcoin/pull/24668

hebasto commented at 2:15 pm on April 7, 2022: member

Looks like pkg-config support will return as of Qt 6.4.0: https://bugreports.qt.io/browse/QTBUG-86080/

Unfortunately, it is disabled for static builds explicitly:

0    if(NOT BUILD_SHARED_LIBS)
1        return()
2    endif()

fanquake commented at 10:36 am on August 10, 2022: member

Going to close this for now. It’s not clear that we’ll actually need the compat library, as it seems (non-build)code-wise, we’ve made all the changes needed to be able to use Qt 6 already. The discussion here has also morphed into more-general updating-qt-talk.

fanquake closed this on Aug 10, 2022

hebasto commented at 10:53 am on August 10, 2022: member

2. Transition from qmake to cmake (see: https://www.qt.io/blog/qt-6-build-system)

Also #25797.

bitcoin locked this on Aug 10, 2023

RFC: Migrate from Qt5 to Qt6’s Qt5 compat #20627