Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
106 views
Skip to first unread message
Helmut Grohne
Dec 7, 2022, 2:10:04 AM12/7/22
to
Package: qmake6
Version: 6.3.1+dfsg-10
Severity: important
Control: affects -1 + src:fcitx-qt5
User: debian...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian...@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
Version: 6.3.1+dfsg-10
Severity: important
Control: affects -1 + src:fcitx-qt5
User: debian...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian...@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
Helmut Grohne
Dec 8, 2022, 6:50:03 AM12/8/22
to
Hi Fab,
please keep debian...@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
please keep debian...@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
Lisandro Damián Nicanor Pérez Meyer
Dec 26, 2022, 8:40:05 AM12/26/22
to
Hi!
As usual I'm a little bit behind this with emails, so I just saw this.
On Thu, 8 Dec 2022 at 08:48, Helmut Grohne <hel...@subdivi.de> wrote:
[snip]
here. Do we need a pass through NEW? If that's the case then that will
need to happen after the next transition, if time allows it. If it can
be easily added to the existing packaging without the need of NEW then
we might add it right now.
Last time you did the packaging with DMitry, so I'm kind of lost here.
Regards, Lisandro.
--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
As usual I'm a little bit behind this with emails, so I just saw this.
On Thu, 8 Dec 2022 at 08:48, Helmut Grohne <hel...@subdivi.de> wrote:
[snip]
> 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.
I would very much prefer (a). Now, as you said, timing is important
> though. And it would be super awesome if this could be included in
> bookworm, so time isn't infinite here.
here. Do we need a pass through NEW? If that's the case then that will
need to happen after the next transition, if time allows it. If it can
be easily added to the existing packaging without the need of NEW then
we might add it right now.
Last time you did the packaging with DMitry, so I'm kind of lost here.
Regards, Lisandro.
--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
Dmitry Shachnev
Dec 26, 2022, 9:03:06 AM12/26/22
to
Hi all,
as I was mentioned in this discussion...
On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.
>
> Last time you did the packaging with DMitry, so I'm kind of lost here.
...I would also prefer if Qt 6 used a similar setup to Qt 5. This way the
transition from Qt 5 to Qt 6 would be more transparent for the reverse
dependencies. E.g. they will only need to replace ${DEB_HOST_GNU_TYPE}-qmake
with ${DEB_HOST_GNU_TYPE}-qmake6.
--
Dmitry Shachnev
as I was mentioned in this discussion...
On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.
>
> Last time you did the packaging with DMitry, so I'm kind of lost here.
transition from Qt 5 to Qt 6 would be more transparent for the reverse
dependencies. E.g. they will only need to replace ${DEB_HOST_GNU_TYPE}-qmake
with ${DEB_HOST_GNU_TYPE}-qmake6.
--
Dmitry Shachnev
Helmut Grohne
Dec 26, 2022, 6:10:03 PM12/26/22
to
Control: tags -1 + patch
On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.
No, (a) does not require going through NEW. There already is qmake6-bin.
qmake6 and qmake6-bin even have the needed Multi-Arch values already.
> Last time you did the packaging with DMitry, so I'm kind of lost here.
Dmitry also expressed being in favour of (a). Notably missing is a
response from Patrick.
In any case, I've attached a patch for it now. It is based on what we do
for qt5.
I caution though that selecting version 5 or 6 is kinda messed up. If
you run qmake6 or <triplet>-qmake6, it'll use qt6 as expected. If you
run plain qmake, it'll go through qtchooser and select the relevant
version via QT_SELECT. Howeve, <triplet>-qmake is presently owned by
qt5-qmake only and will bypass qtchoser without honouring QT_SELECT. If
we want "QT_SELECT=6 <triplet>-qmake" to run the cross qt6 qmake, we'll
also have to modify qtchooser and qt5-qmake.
Helmut
On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.
qmake6 and qmake6-bin even have the needed Multi-Arch values already.
> Last time you did the packaging with DMitry, so I'm kind of lost here.
response from Patrick.
In any case, I've attached a patch for it now. It is based on what we do
for qt5.
I caution though that selecting version 5 or 6 is kinda messed up. If
you run qmake6 or <triplet>-qmake6, it'll use qt6 as expected. If you
run plain qmake, it'll go through qtchooser and select the relevant
version via QT_SELECT. Howeve, <triplet>-qmake is presently owned by
qt5-qmake only and will bypass qtchoser without honouring QT_SELECT. If
we want "QT_SELECT=6 <triplet>-qmake" to run the cross qt6 qmake, we'll
also have to modify qtchooser and qt5-qmake.
Helmut
Patrick Franz
Dec 26, 2022, 6:40:04 PM12/26/22
to
Hi,
I agree that solution a) sounds like the better option, especially since
we've gone this route with Qt 5.
However, I will revisit this issue once we have transitioned 6.4 into
unstable.
--
Med vänliga hälsningar
Patrick Franz
I agree that solution a) sounds like the better option, especially since
we've gone this route with Qt 5.
However, I will revisit this issue once we have transitioned 6.4 into
unstable.
--
Med vänliga hälsningar
Patrick Franz
Lisandro Damián Nicanor Pérez Meyer
Dec 26, 2022, 9:20:05 PM12/26/22
to
Hi,
> I caution though that selecting version 5 or 6 is kinda messed up. If
> you run qmake6 or <triplet>-qmake6, it'll use qt6 as expected. If you
> run plain qmake, it'll go through qtchooser and select the relevant
> version via QT_SELECT. Howeve, <triplet>-qmake is presently owned by
> qt5-qmake only and will bypass qtchoser without honouring QT_SELECT. If
> we want "QT_SELECT=6 <triplet>-qmake" to run the cross qt6 qmake, we'll
> also have to modify qtchooser and qt5-qmake.
We don't want to mix qtchooser and Qt 6. qtchooser is currently
deprecated and will disappear with Qt 5. It's not worth the effort to
remove it right now (I think). so the current behavior makes sense.
Thanks!
--
> In any case, I've attached a patch for it now. It is based on what we do
> for qt5.
Thanks!
> for qt5.
> I caution though that selecting version 5 or 6 is kinda messed up. If
> you run qmake6 or <triplet>-qmake6, it'll use qt6 as expected. If you
> run plain qmake, it'll go through qtchooser and select the relevant
> version via QT_SELECT. Howeve, <triplet>-qmake is presently owned by
> qt5-qmake only and will bypass qtchoser without honouring QT_SELECT. If
> we want "QT_SELECT=6 <triplet>-qmake" to run the cross qt6 qmake, we'll
> also have to modify qtchooser and qt5-qmake.
deprecated and will disappear with Qt 5. It's not worth the effort to
remove it right now (I think). so the current behavior makes sense.
Thanks!
--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
Lisandro Damián Nicanor Pérez Meyer
Dec 26, 2022, 9:20:05 PM12/26/22
to
Hi,
On Mon, 26 Dec 2022 at 20:36, Patrick Franz <delt...@debian.org> wrote:
>
> Hi,
>
> I agree that solution a) sounds like the better option, especially since
> we've gone this route with Qt 5.
>
> However, I will revisit this issue once we have transitioned 6.4 into
> unstable.
It's up to you, but the patch is straightforward and will not
introduce any problems with the transition.
--
On Mon, 26 Dec 2022 at 20:36, Patrick Franz <delt...@debian.org> wrote:
>
> Hi,
>
> I agree that solution a) sounds like the better option, especially since
> we've gone this route with Qt 5.
>
> However, I will revisit this issue once we have transitioned 6.4 into
> unstable.
introduce any problems with the transition.
--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
0 new messages