Qt6 moving towards cmake

[pljones]

What is the current behaviour and why should it be changed?

Currently Jamulus is built predominantly with qmake and a Jamulus.pro project file specifying the cross-platform build specification.

Qt6 is moving away from the use of qmake and project files. For example, it is no longer possible to use qmake and androidinstallqt to produce an Android multi-ABI APK/AAB.

The recommended tooling is based around cmake and there is a project-provided migration tool to move from qmake to cmake.

However, it comes with a number of provisos and the output would need to be reviewed carefully for each target platform to ensure that Jamulus remains buildable on those platforms.

We also need to investigate the use of cmake for the legacy builds.

Describe possible approaches

• Drop Qt
  One option is to take this as the point at which we decide that Qt is no longer the right cross-platform development environment for Jamulus.
  The obvious downside is there is a very large amount of work involved in porting to any other platform - primarily the UI but also the inter-component communication, networking and audio.
• Halt updates to Qt, supply only Qt5 builds for Android and do not look to publish Jamulus on Play Store
  Clearly this saves a lot of work. However, it's likely to mean that support for Android is dropped in the medium term.

Given there is no simple solution, the least bad solution is probably to take the hit on Qt6:

• Split into Qt5 (legacy) and Qt6 (modern) work streams
• Migrate the Qt6 builds to cmake
• Pin the legacy builds to "last known working versions" of all dependencies

Has this feature been discussed and generally agreed?

No. We need to come up with an agreed plan.

[pljones]

Of course, there's another alternative I missed:

• Do not deliver a single fat APK for Android - use androiddeployqt "as is" and have four separate APKs.

It's less work to add support for eight outputs from the AutoBuild matrix (or we make the debug stream another manual build option and have four) but means never getting to Play Store.

[mcfnord]

🤖 AI: I ran qmake2cmake 1.0.8 on Jamulus.pro at 43718fdb with --min-qt-version 6.2. It exits 0 with no warning and writes 892 lines, but the result does not configure: project(... VERSION 3.12.5dev) is rejected at line 2, and target_compile_options(Jamulus -ftree-vectorize) has no scope keyword. Dropped silently: the eight client files in SOURCES_GUI, SOURCES_JACK, the oboe $$files() glob (copied as literal text), every QMAKE_* setting including /DYNAMICBASE:NO and the SSE per-file compilers while OPUS_HAVE_RTCD=1 stays defined, and the TRANSLATIONS list. Qt::AndroidExtras is kept as a Qt 6 component (#2528).

Of the nine CI configurations in autobuild.yml, three build on Qt 6.10.2 (macOS and both Windows x64 builds); the other six, Android and iOS among them, are on 5.15.2, so the Qt5/Qt6 split already exists. The Android premise is stated outright in Qt's own docs: "Building multi-ABI packages with qmake is not supported in Qt 6".

Hand-fixing the output is a longer road than the clean exit suggests: seven scripted edits took it to a linked, running binary on Linux (Qt 6.8.2, aarch64) and nine on Windows (Qt 6.10.2, MSVC), each round exposing another silent drop — no AUTOUIC, the client .ui files, the client sources, the JACK sources and their PKGCONFIG line, and every ARM and x86 Opus source, so both binaries run generic-C Opus. The two Windows-only rounds were Qt 6 facts the converter cannot know: AUTOMOC hands moc no _WIN32 (so it mocs the POSIX branch of CSignalHandler; AUTOMOC_MOC_OPTIONS fixes it), and DEFINES -= UNICODE (the ASIO SDK's asiolist.cpp) is qt_disable_unicode_defines() in cmake.

[ann0see]

I think we'll need to move to cmake in the medium term and then slowly move away from Qt in the long term.

The conversion to cmake should be a perfect application of AI (under supervision and testing). We should probably do it step by step...