Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hello,
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.
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 ?
Regards
Fab
On Wed, 7 Dec 2022 08:04:54 +0100 Helmut Grohne <helmut@subdivi.de> wrote:
> 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.
Reply to: