cmake: Fix `FindQt` module #32709

can be helpful on some systems.

Can we document something more specific; I'm guessing this doesn't close #32536?

can be helpful on some systems.

Can we document something more specific;

What do you have in mind?

I'm guessing this doesn't close #32536?

Correct, it doesn't. The Qt6_DIR cache variable can be set by the user to specify the location of a Qt 6 package that CMake cannot discover for some reason. The user should be able to see this variable in CMake's cache.

What do you have in mind?

I don't know, because it's not clear from the commit or documentation why this is needed. I'd rather we document nothing than something vague like "can be helpful on some systems."

I'd rather we document nothing than something vague like "can be helpful on some systems."

OK. The comment has been dropped.

In 89d3daf823e4350667b42473c0924430ea7400bc: Why is XKB_* being added here?

They are created by Qt 6 configuration scripts internally.

Consider the following:

$ rm -rf build && cmake -B build --log-level=ERROR -L | tail -n +5 > /tmp/master_no_gui
$ rm -rf build && cmake -B build -DBUILD_GUI=ON --log-level=ERROR -L | tail -n +5 > /tmp/master_gui
$ diff -u /tmp/master_no_gui /tmp/master_gui
--- /tmp/master_no_gui	2025-06-16 14:47:31.494243561 +0100
+++ /tmp/master_gui	2025-06-16 14:48:25.931426493 +0100
@@ -8,7 +8,8 @@
 BUILD_DAEMON:BOOL=ON
 BUILD_FOR_FUZZING:BOOL=OFF
 BUILD_FUZZ_BINARY:BOOL=OFF
-BUILD_GUI:BOOL=OFF
+BUILD_GUI:BOOL=ON
+BUILD_GUI_TESTS:BOOL=ON
 BUILD_KERNEL_LIB:BOOL=OFF
 BUILD_SHARED_LIBS:BOOL=ON
 BUILD_TESTS:BOOL=ON
@@ -22,6 +23,12 @@
 ENABLE_IPC:BOOL=OFF
 ENABLE_WALLET:BOOL=ON
 INSTALL_MAN:BOOL=ON
+QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH:STRING=
+QT_ADDITIONAL_PACKAGES_PREFIX_PATH:STRING=
+Qt6CoreTools_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt6CoreTools
+Qt6DBusTools_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt6DBusTools
+Qt6GuiTools_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt6GuiTools
+Qt6WidgetsTools_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt6WidgetsTools
 REDUCE_EXPORTS:BOOL=OFF
 SECP256K1_APPEND_CFLAGS:STRING=
 SECP256K1_APPEND_LDFLAGS:STRING=
@@ -44,7 +51,13 @@
 SECP256K1_INSTALL:BOOL=OFF
 SECP256K1_USE_EXTERNAL_DEFAULT_CALLBACKS:BOOL=OFF
 SECP256K1_VALGRIND:STRING=AUTO
+SED_EXECUTABLE:FILEPATH=/usr/bin/sed
 WERROR:BOOL=OFF
 WITH_CCACHE:BOOL=ON
+WITH_DBUS:BOOL=ON
+WITH_QRENCODE:BOOL=ON
 WITH_USDT:BOOL=OFF
 WITH_ZMQ:BOOL=OFF
+XGETTEXT_EXECUTABLE:FILEPATH=/usr/bin/xgettext
+XKB_INCLUDE_DIR:PATH=XKB_INCLUDE_DIR-NOTFOUND
+XKB_LIBRARY:FILEPATH=XKB_LIBRARY-NOTFOUND

If they are internal, why do we need to do anything? It seems odd that we'd need to do something specifically, for this single Qt dependency. This doesn't really explain why this is needed.

CMake’s normal (non-advanced) cache variables are intended for users to override values set by the build system. I believe we should keep the list of such variables concise, including only those that may be genuinely useful to users.

Ok. So then this looks like a bug in Qt.

To be clear, I think these changes could be made, with the XKB_ change dropped. If that's going to be kept, then there should be a link to an upstream issue.

I don't think upstream considers this as an issue. Whether those variables should be considered advanced or not is a matter of taste.

If anything, that would seem inconsistent, because they have marked every other dependency as advanced, and there's no explanation for why XKB hasn't been marked as such (my guess is just oversight).

Is this going to be addressed / reported upstream? I'd rather not undocumented work arounds, for suspected upstream issues (given that they mark all other dependencies as advanced), just to fix the output of a GUI tool.