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

[Thiago Macieira]

On Sunday 18 January 2015 02:41:52 Kevin Kofler wrote:
> Oh, and another inherent complication that Rex Dieter (our qtchooser
> packager) reminded me of: In Fedora, we support multilib. Now
> /etc/xdg/qtchooser is a non-multilibbed path. If we install an
> /etc/xdg/qtchooser/5.conf in both qt5-qtbase-devel.i686 and
> qt5-qtbase-devel.x86_64, pointing to /usr/lib/qt5 and /usr/lib64/qt5,
> respectively, the differing files will cause a file conflict. (Why do we not
> have that file conflict for /usr/bin/qmake-qt5? Because that's an ELF
> binary (we use hardlinks there) and RPM automatically prefers the 64-bit
> version of ELF binaries. This RPM "coloring" magic does not work on text
> files such as /etc/xdg/qtchooser/*.conf.)

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.

> So we actually have to install 5-32.conf and 5-64.conf and then use the
> "alternatives" system (another hackish approach actually quite similar to
> qtchooser, but based on symlinks rather than wrapper scripts, and thus also
> usable on text files) to set the 64-bit version as the preferred one (the
> one to symlink 5.conf to) if both are present (otherwise, it obviously picks
> the one that's present). (By the way, I do NOT propose to use
> "alternatives" to handle /usr/bin/qmake. That approach is flawed in several
> other ways, the main one being that it's a systemwide setting, not even per
> user.)

Agreed, alternatives for qmake is not desirable. We discussed that in 2011 and 
discarded it because it's a global solution, not per user, per shell or per 
invocation, and only available to the admin.

However, alternatives for the configuration files was part of the design.

It turned out, later, that Debian refuses to use alternatives for files in 
/etc...

> Requiring "alternatives" to configure something that is supposed to be a
> better alternative to "alternatives" (qtchooser) strikes me as a major
> design flaw in qtchooser. One way to avoid that issue would be to look for
> the config files somewhere under the libdir (/usr/lib64 and /usr/lib),
> rather than or in addition to /etc/xdg. That's how pkg-config does it, for
> example. Or qtchooser could try to append "-64" and "-32" to the
> configuration name automatically.

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. Moreover, the config files 
are text, they don't belong in /usr/lib. And they're config files.

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. 

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.

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

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center