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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
