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. I have a preference for a) at this time, because it's changing one package versus a rabbit hole. Do you agree? Helmut
