Remove obsolete Qt version checks#329
Conversation
1a46cf9 to
1d7295b
Compare
|
I believe you are correct, and should have been flagged for deprecation when we stopped supporting 32 bit builds. |
Joe-K0OG
left a comment
There was a problem hiding this comment.
After building on Linux (Mint 22.3, Ubuntu Server 24.04), and Windows (QtCreator and JTSDK64-Tools), it seems to build and run fine. I found one minor glitch with the JTSDK64-Tools build system in that the version parser script now finds "6.9.3" instead of "0.0.0" in CMakeFiles.txt and for the life of me I can't find what changed that would cause this. Strange! If I change the version to "1.0.0" or any other non-zero number, it picks up that version number. Not the JS8Call team's problem though, so don't worry about that.
I say it's good to go.
73,
-Joe-
K0OG
|
P.S. I've been doing occasional test builds with Qt6.11.1 and it seems to work fine so far. 73, |
F.Y.I - I found the problem with JTSDK64-Tools -- the CMakeLists.txt parser script was not robust enough, so I fixed it by adding that it should look for a line with "VERSION" followed by a number, and now it works perfectly. I report this just to prove that it is not a problem with JS8Call source in any way. I reported this to the development team. 73, |
|
The version is actually gotten internally in CMake. It is passed into the compiler via target_compile_definitions A generated config header: configure_file(JS8_Include/js8call_config.h.in -> js8call_config.h) is created, and then precompiled with:
I don't imagine JTSDK64-Tools can use this due to their non-standard toolchain, and they're probably using gcc instead of LLVM-clang. Parsing CMakeLists.txt is not necessarily a recommended way to do it. Because even the git hash for a development build will be extracted and created when CMake runs and assigned to JS8CALL_VERSION and the GIT_SHORT variables, then compiled into the js8call_config.h header. It is a much more advanced versioning system than what WSJT-x used, without all the extra cruft that that old convoluted version "computing" system used to go thru. |
This is a general code cleanup that removes all obsolete Qt version checks. And wires in two sources of truth for Qt version; configure time and compile time in the event somebody tries to override the configure time setting.
We are NOT supporting distro-packaged JS8Call builds where maintainers are building JS8Call against Qt6.8.1 because that's what's packaged in Debian trixie, and modifying code to get it to work. They are inventing their own support issues with that one, especially after an email exchange I had with Christoph Berg, head of the Debian Hamradio Maintainer's. When we move to Qt 6.11 to take advantage of the new callback-based audio API in QtMultimedia, bypassing the need for a QIODevice, they are going to find out why we code for and require a specific version of Qt for our builds.
This was a literal mess, most of which I suspect came from WSJT-x. I was surprised to see it in the (relatively) new WSJTXMessageClient.cpp, which was obviously copied from WSJT-x code.