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 <hel...@subdivi.de> wrote: > Package: qmake6 > Version: 6.3.1+dfsg-10 > Severity: important > Control: affects -1 + src:fcitx-qt5 > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > X-Debbugs-Cc: debian-cr...@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.