Hi,
On Sat, 11 Feb 2023 at 05:54, Dmitry Shachnev <mity...@debian.org> wrote:
>
> Hi all,
>
> On Thu, Feb 09, 2023 at 11:59:43AM +0100, Helmut Grohne wrote:
> > Hi,
> >
> > thanks for adding the <triplet>-qmake6 wrapper. This piece seems to work
> > fine. The next step is making packages actually use it and this is where
> > it gets difficult.
> >
> > fcitx-qt6 extracts the Qt6::qmake IMPORTED_LOCATION and expects to find
> > a working qmake there. What it gets is the build architecture qmake
> > instead of our lovely wrapper. Bummer.
> >
> > I looked into how this could be fixed and got entangled in the mess of
> > cmake files until I completely lost track. What I found is that the
> > imported location is (wrongly) defined in
> > /usr/lib/<triplet>/cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake as
> > ${_IMPORT_PREFIX}/lib/qt6/libexec/qmake aka /usr/lib/qt6/libexec/qmake
> > while it should be /usr/bin/<triplet>-qmake6. Tracking down how this
> > file is generated is where I failed. Would someone be available to
> > support me with that task?
>
> In Qt 5 I simply patch that file using sed after dh_auto_install:
>
> https://salsa.debian.org/qt-kde-team/qt/qtbase/-/blob/debian/5.15.8+dfsg-2/debian/rules#L285-L286
>
> So for Qt 6 something like this may work:
>
> sed -i 's,lib/qt6/libexec/qmake,bin/$(DEB_HOST_GNU_TYPE)-qmake,' \
>
> debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake
That's an excellent workaround, but shouldn't that path be different?
If so I can open a bug upstream.
--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
