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

[Kevin Kofler]

Thiago Macieira wrote:
> Which implies that the Qt 5 development files install a "5.conf" global
> configuration file. That's all.

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.)

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.)

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.

        Kevin Kofler