Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?

[Helmut Grohne <helmut@subdivi.de>]

Hi Fab,

please keep debian-cross@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