Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Package: qmake6
Version: 6.3.1+dfsg-10
Severity: important
Control: affects -1 + src:fcitx-qt5
User: debian-cross@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-cross@lists.debian.org
Hi,
we've hit an interesting issue with qmake for QT6. This almost certainly
is a pattern and I'll use fcitx-qt5 as an example.
fcitx-qt5 looks for a target Qt6::qmake and queries its LOCATION
property to be able to run it. Then it runs that with -query
QT_INSTALL_PLUGINS to locate the installation directory for plugins.
Unfortunately, what it gets is the build architecture one rather than
the host architecture one.
The crux of this is that /usr/bin/qmake6 cannot know about the host
architecture. That information is a parameter of the build and nothing
has passed this information along to it. It cannot just pull this
information out of nothing. So we basically have two options:
a) Make sure that Qt6::qmake's LOCATION resolves to something that
includes the information of the host architecture somehow.
b) Declare that this method of querying qmake is unsupported and fix
every package (including fcitx-qt5) in some other way.
For b), I have no clue what that other way would be. If someone knows,
that would be great. I also have little clue how frequent this pattern
is and how many packages we would have to fix. The expectation is "many"
from my experience with QT5.
The implications of a) are quite well understood, because that's the
route we opted for with QT5. It's a fairly involved route that took us
more than a year to work properly, but maybe we can speed up by learning
from earlier mistakes, so how does it work?
The qmake6 package gains new binaries /usr/bin/<triplet>-qmake6. These
actually are shell scripts that wrap qmake6 and inject the information
about the host architecture into the command line. Then, we centrally
divert Qt6::qmake to this location and everything will magically work.
To get an idea how this works, install qt5-qmake and look at
/usr/bin/$(dpkg -qDEB_BUILD_GNU_TYPE)-qmake. That should be fairly
obvious. We're in a far better position than we started with QT5 as we
already have the necessary qmake6 vs qmake6-bin split in place in
exactly the way it needs to be. Also a number of client packages have
been switched from AC_PATH_PROG to AC_PATH_TOOL for locating qmake
already.
What we need now is a choice on which way we do it. The choice
essentially is:
a) Add architecture-specific qmake wrappers for QT6.
b) Declare that running qmake6 -query SOMEVAR is unsupported.
Patrick and Pino, what's your thoughts on this? If you feel like you
cannot make such a choice, let us figure out what information is
missing.
I have a preference for a) at this time, because it's changing one
package versus a rabbit hole. Do you agree?
Helmut
Reply to: