[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Kevin Kofler]

Thiago Macieira wrote:
> It would have been nice to know this limitation when we were designing the
> solution. Other distros don't seem to have this problem because the 32-bit
> package on a 64-bit system does not seem to have clobbered files.

Even we did not know it. We only found out when we started shipping
qtchooser configurations in qt*-devel packages and users reported the
resulting multilib conflicts to us, which was fairly recently (because there
was strong opposition from the primary Qt maintainer in Fedora (Than Ngo)
and from me to supporting qtchooser in Fedora in any way at all).

> That wouldn't work for one major use-case which was to find options for
> other targets too. We *want* to be able to run "qmake -qt5-32" or "qmake
> -qt5-i386" or whatever (non-standardised yet) so you can do a 32-bit build
> on a 64-bit system or "qmake -qt5-arm" for an ARM build on x86.

Symlink:
/usr/lib/qtchooser/5.conf → /etc/xdg/qtchooser/5-32.conf
/usr/lib64/qtchooser/5.conf → /etc/xdg/qtchooser/5-64.conf

> Moreover, the config files are text, they don't belong in /usr/lib.

.pc files are text too. They belong into /usr/lib* because they depend on
the architecture and thus need to be multilibbed, and /usr/lib* is the only
multilibbed subdirectory of /usr.

> And they're config files.

My symlink approach would solve that problem too. (You can still edit the
actual file under /etc/xdg.)

(That said, to be clear, solving the multilib issue would only address one
of the several major design flaws in qtchooser that I have pointed out.)

> Now, qmake has a major limitation that you're supposed to replicate the
> entire qmake + mkspecs and all the Qt includes for a 32-bit build on a
> 64-bit system. This is a known problem and one we would like to address,
> but it's low priority.

Indeed, that would finally obviate the need to multilib qmake at all,
letting us go back to our past approach of MOVING qmake to
/usr/bin/qmake-qt5, letting RPM pick the preferred architecture with its
ELF "coloring" magic, and making BOTH /usr/lib/qt5/bin/qmake and
/usr/lib64/qt5/bin/qmake symlinks pointing to it (also known as the
"inverted symlink" approach). We moved away from doing that exactly to allow
using 32-bit qmake on 64-bit hosts (by giving the full path). For our users,
it would mean both an easier way to build 32-bit software and reduced disk
space usage for multilib installations.

It would also mean yet one less use case for qtchooser. :-)

> Note how qmake in Qt 5 does understand the difference between "ARCHDATA"
> (arch- depedent data, which in distros lives in /usr/lib$suffix) and plain
> DATA (non- dependent, which could live in /usr/share). That was the
> beginning of the work and it remains incomplete.

That is indeed useful and wanted.

> Until it's complete, using the 64-bit headers for a 32-bit build is also
> unsupported. Help from distros would be appreciated.

For headers, we use the "qconfig-multilib.h" hack:
http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/qconfig-multilib.h
with this specfile snippet:
%ifarch %{multilib_archs}
# multilib: qconfig.h
  mv %{buildroot}%{_qt5_headerdir}/QtCore/qconfig.h %{buildroot}%{_qt5_headerdir}/QtCore/qconfig-%{__isa_bits}.h
  install -p -m644 -D %{SOURCE5} %{buildroot}%{_qt5_headerdir}/QtCore/qconfig.h
%endif
(We use the same trick for Qt 4, and have been doing so for years.)

With that, the headers end up identical for 32-bit and 64-bit Qt (if they
weren't, the packages would fail to install, for the same reason as with the
qtchooser conf files), so things should just work. (It can't matter which
headers you use because they're byte-identical, which is enforced by RPM.
The only header that actually ends up different is qconfig.h, which is
handled by "qconfig-multilib.h".)

        Kevin Kofler