Skip to content

Remove obsolete Qt version checks#329

Merged
Chris-AC9KH merged 2 commits into
JS8Call-improved:masterfrom
Chris-AC9KH:pr/Qt_cleanup
Jun 15, 2026
Merged

Remove obsolete Qt version checks#329
Chris-AC9KH merged 2 commits into
JS8Call-improved:masterfrom
Chris-AC9KH:pr/Qt_cleanup

Conversation

@Chris-AC9KH

Copy link
Copy Markdown
Collaborator

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.

@Chris-AC9KH Chris-AC9KH added the administration administration of JS8Call-improved project label Jun 14, 2026
@wmiler

wmiler commented Jun 14, 2026

Copy link
Copy Markdown
Collaborator

I believe you are correct, and should have been flagged for deprecation when we stopped supporting 32 bit builds.

@Joe-K0OG Joe-K0OG left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Joe-K0OG

Copy link
Copy Markdown
Collaborator

P.S. I've been doing occasional test builds with Qt6.11.1 and it seems to work fine so far.

73,
-Joe-
K0OG

@Joe-K0OG

Copy link
Copy Markdown
Collaborator

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.

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,
-Joe-
K0OG

@Chris-AC9KH

Copy link
Copy Markdown
Collaborator Author

The version is actually gotten internally in CMake. It is passed into the compiler via target_compile_definitions

target_compile_definitions(${TARGET}
      PRIVATE
      CMAKE_BUILD
      JS8CALL_VERSION=\"${PROJECT_VERSION}\"
      GITSHORT=\"${GIT_HASH}\"
      MACHINE=\"${HOSTNAME}\"
      UNAME=\"${USERNAME}\"
  )

A generated config header: configure_file(JS8_Include/js8call_config.h.in -> js8call_config.h) is created, and then precompiled with:

target_precompile_headers(${TARGET} PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/js8call_config.h)

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.

@Chris-AC9KH Chris-AC9KH merged commit 47009b1 into JS8Call-improved:master Jun 15, 2026
4 checks passed
@Chris-AC9KH Chris-AC9KH deleted the pr/Qt_cleanup branch June 15, 2026 01:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

administration administration of JS8Call-improved project

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants