Qt 6.11.1 Migration#331
Conversation
gcc will complain about it. Did not add a default: switch for gcc as this is coded primarily for LLVM-clang - Replace deprecated invalidateFilter() with the Qt 6.11 pattern beginFilterChange() / endFilterChange()
… 6.11, use the standard C++17 or later library utility std::as_const which replaces qAsConst - Configuration.cpp: the parameters, allow_monitors and show_monitors, are only used on Linux in a preprocessor guard. Silence the compiler spam for Mac and Windows which see them as declared but unused parameters
…checks - cast numeric_limits to double explicitly before comparison/division in Radio.cpp and FrequencyLineEdit.cpp
…ated. Code will not build on Qt6.9 so set minimum Qt required version to 6.11 or newer
internally built and hosted Qt6.11.1 library package. This is necessary because Qt6.11.1 is not available in the jurplel/install-qt-action pipeline for either LLVM-clang or mingw/gcc - switch linux builds to clang 18 - move Qt6 package script for linux to js8lib
|
Oh, and many thanks to Joe for all his testing and behind-the-scenes work to make this possible. |
…running on in the runner logs.
|
After watching the new workflows run on a production repo, I pushed one minor little change to the linux build script so it shows in the runner logs the actual PR branch that the workflow is running, even it doesn't exist on JS8Call-improved. Which for a PR it normally doesn't exist. But the contributor branch the PR is submitted on is available in the So it's a little attention-to-detail that's nice to have in the runner logs: Active CI Target Branch: pr/Qt6.11_migration |
Joe-K0OG
left a comment
There was a problem hiding this comment.
After building on Linux Mint 22.3, Ubuntu 24 Server (AppImage), Win11 (QtCreator), and Win11 (JTSDK64-Tools), as well as downloading the CI-built AppImage (tested on Mint and Fedora) and Windows installer, I find that all build, install, and run without any problems.
Excellent work Chris! The move to Qt6.11.1 was not too painful.
73,
-Joe-
K0OG
|
It's fairly straightforward if all the pieces are in place so it can be done in one step. If a gradual transition was tried, it would be a disaster. This branch, upon merge, effectively becomes master. I would like @wmiler thoughts on it simply because some of the linux "purists" are likely going to have a cow over using the LLVM/Clang toolchain instead of gcc to build linux binaries. We have no choice with Qt 6.11 so it's kinda like the forced ALSA audio deprecation in Qt 6.10, which we prepared for on Qt 6.9. Prior to that we were building linux on, what? Qt 6.4? Windows with 6.8.1 for OmniRig. Mac on Qt 6.8.3. Which is an un-maintainable mess in the code. Preprocessor guards to get Windows audio to work. About 20 Qt version checks for linux with preprocessor directives compiling different code on linux than on Mac or Windows. Ask the Google about why the Qt Group is switching to LLVM/Clang and you get this, and it kinda boils down to x86_64 being "old news" in modern computing. While it's not going away any time soon, it will still go out the door kicking and screaming because it was so deeply embedded in the Windows world. But Microsoft no longer controls that. So you can either get with the program or be left in the dust. 
|
It's not so much that Linux folks will have a cow, it's just what we are use too and the kernel compiles with it, and also some major users just don't update their OS as often as more consumer oriented developers expect. This is mainly due to fault tolerance, and preventing unforced errors. M$ doesn't care, as can be seen from the multiple failures they have had. I'm not opposed to moving to Clang, and is definitely better than the MinGW mess. It does seem that Clang on Linux is moving to parity with the other platforms.
This was the right move to get us all on the same version of QT from a maintainability viewpoint.
X86_64 systems are prevalent in the world, it's really about whether you need newer hardware for your use case or not, and there are a lot of non-TPM2 systems that are still on Win10 either due to necessity or cost. Just because the vendor doesn't provide updates, does not mean the system is unusable. @Joe-K0OG Any chance you ran this PR output on Ubuntu 22.04? Would be interesting for verification purposes. The switch for most people to 26.04 won't happen before August. Per Ubuntu:
One other platform you can try if you just want to have some fun, the AppImage should run on SteamOS... 🙄🤪 |
wmiler
left a comment
There was a problem hiding this comment.
Given that this contains breaking changes, this should fall on v4
@wmiler @Chris-AC9KH Unfortunately, the AppImage built with this latest, Qt6.11.1, won't run on Ubuntu 22.04 because glibc is at 2.72, and it requires 2.38. I haven't tried to hack it to get it to build, but suspect I would break Ubuntu 22 if I tried that. 73, P.S. Yes, I agree that this is such a big change that it should be designated JS8Call v4. |
My bad, forgot about that. We will need a note in the Linux docs that v4 will only run on 24.04 or newer.
|
|
@wmiler this is definitely a JS8Call 4.0 change. Any further JS8Call 3.0 releases will be running on Qt 6.9.3, built with the older workflows in the release/3.0.2 branch against js8lib v3.0 libraries.
History of LLVM/Clang: Apple remains as a major contributor to the open-source clang code, particularly for arm64 RISC-V chips. But all the major players; Microsoft, Google, Intel, Nvidia, IBM, AMD, Qualcomm, Sony et al, contribute. Today, the development and maintenance of the LLVM ecosystem is a global, highly collaborative effort that includes all top tech corporations, university computer science dept's (mainly thru programs like Google Summer of Code), and independent developers Linux has reaped the benefits of this without having to do very little of anything. So there's no technical issues with it on linux. The main issue is political and licensing for the linux ecosystem, and the fact that it doesn't use GNU libraries. Linux can't take the LLVM/Clang toolchain and license it GPLv3. And any contributions the linux community makes can be made proprietary by the major players that support it. This gets the linux "purists" panties all in a bundle. The GPLv3 fiasco was the defining turning point that broke the relationship between big tech companies and the GNU Project. GPLv3 was specifically designed to close legal "loopholes" that corporations were using under GPLv2. Instead of forcing compliance, it triggered an absolutely massive corporate migration to LLVM/Clang, headed up by Apple. That's the LLVM/Clang ecosystem in a nutshell. |
|
Some more comments on this for posterity sake: I did not force the use of LLVM/Clang for the end-user linux builds. It is not reasonable to expect end-users to install the LLVM/Clang toolchain to build JS8Call. They will get some non-breaking gcc-specific compiler spam since the code has been optimized for LLVM/Clang. But it will still build and run. @Joe-K0OG I did NOT update the JTSDK-Tools section for Windows build instructions and instead marked it largely deprecated and left there for reference. If you want to update that, you can. To do that:
Same applies to the Linux build instructions. I added a section at the top explaining that linux builds are extremely easy with our automated build script for Debian/Fedora/Arch. But the instructions below that are overly complex, branching off into docker, building different versions of Hamlib, and other stuff like CPack that was deprecated long ago. So I left that as-is. One of the linux guys will have to fix that because reading it makes my head swim. And attempting to follow those convoluted instructions fails to work on Debian 13 arm64 to build this branch. I ran into this on the forum where there was a guy trying to build JS8Call using those instructions, and kept getting failure after failure. I pointed out that we got automated scripts that can do it. He grabbed that and it worked out-of-the box. |
I don't know that that needs to go in the linux docs. Isn't that more of a Release Notes thing at release time? MacOS Intel is deprecated as well. And minimum deploy target moved to MacOS 14 Sonoma. Although I could technically move the minimum deploy target to MacOS 13 Ventura, why do that when Apple doesn't support it? So I view this as a Release Notes thing. Minimum OS versions required:
It positively will not run on MacOS 13. If Windows users can get it to work on Windows 10, that's great. If somebody has linux glibc 2.38 and it runs, that's great. The Release Notes specifically outline the OS requirements. |
There may be some move eventually of the JTSDK64-Tools to support LLVM-clang, but I don't know when or if that might happen. I suppose I could work on trying to make that happen, but on a quick overview of what might be required, I'm ill-equipped to do it since I'm not really a software engineer, but a hardware engineer. In fact, since I have such a fine working QtCreator build system running now, and know how to use it (thanks to much help from @Chris-AC9KH!), I don't have much need or motivation to work on JTSDK64-Tools migration to LLVM-clang. 73, |
|
Qt Creator actually works on all three platforms for a JS8Call build. And the setup is even pretty much the same on all, except for the cmake prefix path to get a valid current configuration. Qt Creator ships with an embedded version of LLVM/Clang (clangd) out of the box on Linux. You can script your library builds with bash shell, say build three different versions of Hamlib, and switch between them for a build by simply changing the prefix path. It's a pretty handy tool for Qt-based projects because it handles the big one - Qt itself - as a "kit" that you install with the Maintenance Tool and it automatically detects what versions of Qt you have installed. |
|
@rruchte It looks like potential conflicts with Configuration.cpp and Configuration.h with this PR and your TCI integration PR. But the changes I made in Configuration.cpp are pretty simple - only five lines of code to fix deprecations and silence compiler spam due to linux-only parameters. And add the include in the header. So it should be fairly simple to fix those conflicts if they pop up on a rebase. I think more important would be to make sure your code is compatible with Qt 6.11, which merging this to master, then rebasing your branch on master will bring in the worklows on your branch to make sure it all builds and runs. So I'll merge this. If you have questions or need help on a rebase, let me know and I'll help you get it fixed up. |
|
I'm pleased to report that the 4.0-a1 CI build runs fine on Win10 Pro 22H2. 73, |
This is a one-step PR to migrate from Qt 6.9.3 to Qt 6.11.1 on master.
It updates:
Along with this a new library backend is in place on js8lib with scripted builds to either build or update libraries used for workflows. While building the backend libs could be fully automated with workflows on js8lib, that is not done at this time. Mainly because building Qt on a runner is not practical. The runners do not have enough power or disk space available to build it.
The workflow runs for this PR are here on my personal repo:
https://github.com/Chris-AC9KH/JS8Call-improved/actions
Upon submission of this PR it is the first time they will run on the production repository.
Note that the linux workflow is now using LLVM-clang instead of gcc. It provides better integration of the Qt libraries, which are now built with clang 18 on linux, per the Qt 6.11 documentation. With Qt 6.11 the Qt Group's tooling and ecosystem are optimized for the LLVM/Clang stack, although gcc is still supported as an alternative. If you attempt to build Qt 6.11 with gcc on linux you will get a warning during configure-time that it is not recommended.