[gentoo-dev] New multi-qt scheme

[Dan Armak]

Hi everyone,

Introducing the new way of managing several QTs. This can also apply to any 
other libraries. General idea by drobbins, but I've made a small change.
This is still a suggestion, and should be well discussed before implementing.

Current scheme: each qt lives in /usr/lib/qt-x11-$ver. It is added to various 
paths (path, rootpath, ldpath, manpath...) from /etc/env.d so that a newer qt 
comes first in the paths. An ebuild using qt has to inherit from kde.eclass 
which contains several pages of ugly convoluted code which selects the 
version of qt to use and sets QTDIR to it so that a configure script can find 
it.

Compile time: mass of ugly code in kde.eclass, which is essentially an 
implementation of a version comparison algorithm with support for _beta etc. 
suffixes in bash, selects version number to use from list of those installed. 
QTDIR is then ste to the dir of the selected QT and --with-qt=$QTDIR is 
passed to configure although that's not strictly necessary.

Runtime: we add the /lib dir of every QT installed to LDPATH and then have to 
juggle them. We also add /bni to PATH and anyone who's developing with qt 
probably doesn't like us for that too much.

The biggest problem is that the eclass code is ugly and is becoming more 
difficult to manage. Also the scheme is inflexible.

New proposed scheme:

Each QT lives in /usr/lib/qt-x11/$ver.
It installs all its files ther, except the libraries, which it installs in 
/usr/lib/qt-x11/lib.
The library symlinks aren't installed.
In /usr/lib/qt-x11/$ver/lib, symlinks are installed for all files that point 
to /usr/lib/qt-x11-lib.

For example, with qt 2.3.1 and 3.0.1 installed, things will look like this:

/usr/lib/qt-x11/
	2.3.1/
		share/...
		bin/...
		include/...
		lib/
			libqt.so		->	../../lib/libqt.so
			libqt.so.2	->	../../lib/libqt.so.2
			libqt.so.2.3	->	../../lib/libqt.so.2.3
			libqt.so.2.3.1	->	../../lib/libqt.so.2.3.1
	3.0.1/
		share/...
		bin/...
		include/...
		lib/
			libqt.so		->	../../lib/libqt.so
			libqt.so.3	->	../../lib/libqt.so.3
			libqt.so.3.0	->	../../lib/libqt.so.3.0
			libqt.so.3.0.1	->	../../lib/libqt.so.3.0.1
	lib/
		libqt.so.2.3.1		# real lib installed by 2.3.1 ebuild
		libqt.so.3.0.1		# real lib installed by 3.0.1 ebuild

A tool I call 'multilib' (for lack of a better name) will be part of portage, 
to be executed e.g. part of env-update. I remember there's an ebuild function 
that does somthing like this, but don't remember what it's called. It will 
for every parameter (e.g. "qt-x11") go to /usr/lib/$1/lib and create the 
necessary symlinks, overwriting any existing ones. Like this:

	lib/
		libqt.so.2.3.1		# real lib installed by 2.3.1 ebuild
		libqt.so.3.0.1		# real lib installed by 3.0.1 ebuild
		# following are symlinks generated by multilib qt-x11, see below
		libqt.so.2		->	libqt.so.2.3
		libqt.so.2.3	->	libqt.so.2.3.1
		libqt.so		->	libqt.so.3
		libqt.so.3		->	libqt.so.3.0
		libqt.so.3.0	->	libqt.so.3.0.1

Note that there is no libqt.so -> libqt.so.2.3.1 symlink! No app should link 
against a qt without at least a major version though.	

multilib will do more than that, it will also create /usr/lib/qt-x11/$ver 
dirs for all versions satisfied by those actually installed. In our example:

	2.2.0/	->	2.3.1/
	2.2.1/	->	2.3.1/
	2.2.2/	->	2.3.1/
	2.2.3/	->	2.3.1/
	2.3.0/	->	2.3.1/
	3.0.0/	->	3.3.1/

And for some others as well (2.0.*, 2.1.*, prerelease 3.0). An ebuild will 
thus have to supply portage with information saying that multilib shuold be 
run on a certain dir, and that this version satisfies dependencies for a 
given list of other versions. By default, it'd satisfy any earlier version 
with the same major version number, but such things as 3.0_beta1 in the 
example above still have to be specified explicitly. But this is a minor 
concern.

Now that we've got everything working, things are made extremely simple.

Compile time:
An application links against the version it needs. It simply looks in 
/usr/lib/qt-x11/$ver for its minimal requirement and presto! it's there. No 
extra code like that currently in kde.eclass is required.

Runtime:
/usr/lib/qt-x11/lib is added to LDPATH. All library versions are thus made 
available.

Development time:
Someone who's developing with a certain QT will have to add its $ver/bin path 
manually to his PATH.

So what do you think?

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel