Hi Fab, please keep debian-cr...@lists.debian.org in the loop. Full quoting.
On Thu, Dec 08, 2022 at 08:29:52AM +0100, Fab Stz wrote: > Not sure this fits your issue and if this could work. > > I used to produce android-builds that are sort of 'target' builds (and not > host builds). There is a specific qmake to be called when building with a > target-build. That qmake is in the bin directory of the target build. And > that > qmake uses the "target_qt.conf" file which should contain the path you expect. Before we delve into this, I'd like to clarify terminology. I'm going to assume that when you say "target" you mean "host" in GNU terminology and when you say "host" you mean "build" in GNU terminology. Please correct me if I got that wrong. I think this is similar to what I called "a" and I'll call your variant "a2" to ease comparison. In both cases, there is a specific qmake (either a binary in case of a2 or a wrapper script in case of a). Both reference separate qtconf. In case of qt5, the wrapper injects a -qtconf argument. The aspect where this differ is the location. In a2 you have the standard qmake6 name on a non-$PATH directory whereas in a, you a different executable name on $PATH. > However, for now, not all path are there and especially the Plugins dir isn't > there. They will be once this is merged: > > https://codereview.qt-project.org/c/qt/qtbase/+/436758/19/cmake/ > QtQmakeHelpers.cmake > > Maybe a solution could be to run qmake by specifying your own target_qt.conf > that has the values you need ? I think we're closer that you might expect. For most non-Debian ecosystems, you need a specific target_qt.conf due to the need for sysroots. It is specific to the combination of build architecture and host architecture (in Qt terminology: host architecture and target architecture). However, cross building on Debian has done away with sysroots and replaced them with multiarch. As such, we can remove the build architecture (in Qt terminology: host architecture) from the configuration and just use the existing /usr/lib/${DEB_HOST_MULTIARCH}/qt6/qt6.conf. This is what we do for qt5 already. To me this reinforces the view that we should rather go for a wrapper than have our build matrix explode into O(n^2) (for n being the count of architectures). Let me give an example: $ dpkg --print-architecture amd64 $ sudo dpkg --add-architecture armhf $ sudo apt update ... $ sudo apt install qmake6:armhf ... $ qmake6 -qtconf /usr/lib/arm-linux-gnueabihf/qt6/qt6.conf -query QT_INSTALL_PLUGINS /usr/lib/arm-linux-gnueabihf/qt6/plugins $ And to do proposal a, we'd have a wrapper /usr/bin/arm-linux-gnueabihf-qmake6 (just like the one for qt5) that would inject the -qtconf argument. So that would become: $ arm-linux-gnueabihf-qmake6 -query QT_INSTALL_PLUGINS /usr/lib/arm-linux-gnueabihf/qt6/plugins $ And then we could point Qt6::qmake at this path. In order to support other workflows, we can also have a separate directory with a symlink to this named just qmake6 to support the sysroot approach. I'd like to get some reply from Patrick before moving forward with this though. And it would be super awesome if this could be included in bookworm, so time isn't infinite here. Helmut