jamulussoftware
Autobuild: Use Qt6 for Windows 64bit
Short description of changes
This PR switches the Autobuilds (and therefore: the releases!) to use Qt 6 for Windows 64bit builds. The PR depends on the already merged PRs #2299 (initial Qt6 code compatibility) and #2328 (build logic Qt6 compatibility) It only contains three small additional commits:
- Autobuild: Windows: Build with Qt 6.3.1 on 64bit 32bit builds remain on 5.15.2, as Qt6 is not available there.
Code-wise this is the smaller change. Change-wise it is the more relevant, more invasive one.
Context: Fixes an issue?
See #2299
Does this change need documentation? What needs to be documented and how?
CHANGELOG: Build: Windows 64bit releases use Qt 6.3.1 now.
Status of this Pull Request
Ready for testing
What is missing until this pull request can be merged?
- [x] Wait for merge of #2299 (Build would fail otherwise)
- [x] Wait for merge of #2328 (Merge will conflict otherwise)
- [x] Testing of all officially supported and affected release artifacts on relevant platforms (via beta/rc)
- [ ] Windows 10
- [x] Windows 11
- [x] Mac
- [x] Check if Qt6 drops support for any older platform versions (docs: Qt5, Qt6)
- [x] Qt6 no longer officially supports Windows 7 and 8.1 (see comments)
- [x] Qt6 no longer supports macOS versions on or before 10.13. I guess that's OK because we still have the legacy build for those users? (@softins: "So if we build with Qt6, High Sierra users on 10.13 would need to start using the legacy build.")
I'm hoping to merge this for 3.9.0, but if any critical issues are found or if there's too little testing, we should postpone it.
Checklist
- [x] I've verified that this Pull Request follows the general code principles
- [x] I tested my code and it does what I want
- [x] My code follows the style guide
- [x] I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
- [x] I've filled all the content above
The PR only contains two more commits compared to #2299. It's based on #2299 (that's why I noted it above and marked it as Draft).
Those two commits have trivial changes and only apply to the build logic, so I'm not sure what to split. Linking them here, but links might change after rebasing: Autobuild: Windows: Build with Qt 6.2.2 on 64bit Autobuild: Mac: Build with Qt 6.2.2 + Xcode 12.4
Can you raise the PR against the appropriate point, rather than master, if it's not the full set of commits?
Can you raise the PR against the appropriate point, rather than master, if it's not the full set of commits?
Yeah, this would be nice, but do you know how? After some research, there doesn't seem to be first-class support for this. What I could do is:
- Push #2299 to a new pr2299 branch in jamulussoftware/jamulus. I'm a bit hesistant to do that though...
- Then I could base this PR (#2300) on pr2299. The "virtual" refs such as pull/ don't seem to work in the selector.
Mmm, no, in that case it's best not to raise the PR until master is ready to receive it, I think. Otherwise it's not really easy to read. There's little worth having a draft PR if it can't enable pre-review, either.
I've rebased to master after merge of #2328. The two relevant commits apply cleanly. Therefore, this PR now looks and feels like it should (commit list, diff). Caveat: It no longer contains #2299, therefore, build is expected to fail until #2299 is merged and #2300 is rebased.
A tree with both #2299 and #2300 can be found at hoffie/jamulus@Qt6-pr2299-and-pr2300. Artifacts should be available here shortly.
I've rebased this PR on current master. As #2299 has been merged, the build of this PR now succeeds as well. I've also updated it to use the latest Qt6 (6.3.0). I've also hidden all the outdated comments regarding PR branch points. I've also updated it to switch iOS as well.
Good to know. I just wanted to add that Qt6.3.0 worked fine on my rehearsal yesterday without UI glitches.
Installing the signed ipa on my phone works, but the app crashes. Hopefully it's not related to the Qt 6 move
Any chance to cross-check a recent Qt5-based build? Also, some kind of debug log would be helpful of course :)
Latest master doesn't crash. I didn't find the crash logs for the version of this PR yet
I think we could move the macOS non-legacy build to use Qt 6.3 only at first. I think that's the version which needs it the most (fixed UI glitches, ARM support).
@pljones should we build macOS only on Qt6 (this allows us to have the legacy version as fall back) since that’s the platform which shows the most glitches on old versions of Qt) (in this release)
Ok. But would you be ok with a macOS Qt6 build. This will NOT drop compatibility to Qt5 but increase compatibility with recent macOS versions. If you and @hoffie are ok with that, I suggest closing this PR and making The necessary changes for macOS non legacy
If it's just the Github builder that's affect, I've no problem with the change (as it doesn't affect anything I do).
I'm not sure where, e.g. debian, for example, stands on Qt6. So we might want to take care around what gets built with Qt6.
Yes. Just macOS on GitHub. I'll raise an alternative PR then
#2672 is the MacOS-only version, I think. Should this PR be closed in favour of that? i.e. are the remaining points here around Windows no longer relevant?
I think the only blocker is that iOS is crashing. Windows worked fine last time I tried it.
The next question, then, is is this a blocker for 3.9.0 - or can it wait for 3.9.1?
iOS can't go in. Windows yes. So no, iOS is not a Blocker. iOS should stay on Qt5
This now has conflicts. Are we still hoping to get it ready for 3.9.0? (It doesn't touch anything the translators need, so there's time.)
This now has conflicts. Are we still hoping to get it ready for 3.9.0? (It doesn't touch anything the translators need, so there's time.)
Rebased now. I've dropped the Mac part (as it was already merged as part of the other PR). Only Windows and iOS remain. I've also updated the PR to use 6.3.1.
I certainly would like to get it in.
@ann0see: It's been some time... can you add some details about the iOS issue? I've only found a single reference (https://github.com/jamulussoftware/jamulus/issues/2363#issuecomment-1110757457). Maybe you can also retry with fresh artifacts from this PR as Qt, Xcode and macOS have been updated meanwhile. If there are still issues, I'm happy to drop iOS from this PR for now.
With regards to Windows, the open questions/blockers are:
- Are we fine with dropping support for Windows 7 and Windows 8? Dropping support does not imply that Jamulus won't work, it just means that there might be issues. I think dropping Windows 7 support is fine as it is no longer supported by Microsoft. The latest Windows 8.1 patch levels still seem to be supported until 2023. I guess we could do it and if there are issues, we could provide a legacy build (still hoping that we don't have to...)?
- Can someone test on Windows 10 and/or Windows 11?
- Are we fine with dropping support for Windows 7 and Windows 8? Dropping support does not imply that Jamulus won't work, it just means that there might be issues. I think dropping Windows 7 support is fine as it is no longer supported by Microsoft. The latest Windows 8.1 patch levels still seem to be supported until 2023. I guess we could do it and if there are issues, we could provide a legacy build (still hoping that we don't have to...)?
I'd rather we went to having a "Legacy" build for out of support Windows operating systems, using Qt5, so that Jamulus can still be used on those platforms. For in support platforms, I think we should retain support in the main build. That means if we need Qt6 for later Windows builds, that should be separate and labelled with the OS version that needs it (e.g. Win11). If there's no pressing need to use Qt6 for any Windows OS, then just stick to Qt5 and keep it simple. (We should continue aiming for Qt6 code compatibility, of course.)
Finally found out (again) how to view iOS crash logs.
You need macOS and The console App.
I think that's the error:
We probably need to change the application class. Or maybe https://forum.qt.io/topic/82102/can-t-create-qapplication-for-ios-using-cmake-build
OK, that sounds like it'll need some (more) platform-specific knitting in main.cpp.
I see no call to UIApplicationMain in main(). Also, for iOS, we use QApplication* to hold the reference rather than QCoreApplication*, which is used everywhere else:
784 QApplication* pApp = new QApplication ( argc, argv );
(Should really be changed.)
If we're going to have to completely change how pApp gets created, we've a bit of an issue. Hopefully there's some other way around it.
@hoffie Please drop iOS being built with Qt6. I think this should be part of the next release. Windows can be updated
I agree that iOS cannot be merged right now. I'll open a separate issue for the further investigation. I'm not sure if we have a common understanding with regards to Windows. The options I see are:
- Continue using Qt5 for Windows. Downside: Qt5 is no longer supported. Personally, I'd like to avoid that as it pushes unsupported software to users and may put us under pressure in case of Qt5 security issues.
- Use Qt6 for Windows. Downside: Windows 7 and Windows 8 are no longer supported. That's what this PR does (besides iOS) and what I would suggest (chances are still good that it works on Windows 7 and Windows 8; combined with the fact that both should be niche by now and are nearing end of support, I'd say that this is acceptable, but I'd understand if someone argues otherwise)
- Provide two builds. Downside: More builds (resources), more user confusion (more download options) a. Qt6-first: Main build is Qt6, a legacy Qt5 build would be advertised as Win7/8 build (that would be similar to our Mac strategy; this would be my second choice). b. Qt5-first: Main build is Qt5, a "next-gen" Qt6 build would be advertised as Win11 build (I think that was @pljones's tendency)