Re: [gentoo-dev] RFC: qt.eclass

[Dan Armak]

On Saturday 02 July 2005 22:41, Gregorio Guidi wrote:
> First, a new eclass for Qt4 ebuilds should really be called qt4.eclass,
> with another one, qt3.eclass, to be used to port the current Qt3-based
> ebuilds. Dealing with more than one major version in a single eclass is a
> pain; this is mostly true for the kde eclasses, but still applies to Qt.
> In fact, we need to introduce a new clean eclass for KDE4-based
> applications, so starting from scratch with a kde4.eclass and a qt4.eclass
> makes a lot of sense.
[...]
> An application based on Qt4 should look just like this:
>
> 	inherit qt4
>
> 	HOMEPAGE=...
> 	SRC_URI=...
> 	...
[...]
> This proposal is meant for Qt, but it should be read as a proposal for both
> Qt and KDE: we can have a kde4.eclass and a kde4-info.eclass that work in
> the same way.

I know you know this, but for other readers, this is exactly the design of the 
current kde.eclass+kde-functions.eclass :-) At least it was until they 
gathered up a huge amount of special cases and backward support. Today a 
typical kde ebuild still looks as simple as that, but sometimes you need to 
know how to work around some sensitive points (like the recent bug where the 
eclass fails to disable the broken visibility support...), and for kde-base 
you also need to know deprange() and some other tricks.

Although the notation PATCHES="$FILESDIR/foo.diff" didn't catch on well enough 
for some reason. Other than me, most people seem to prefer to override 
src_unpack just to call epatch...

So if we ever get a chance to cleanup the existing kde3 eclasses they'll look 
just like that, and might even share some code with the new kde4 eclasses 
(which should be separate due to kde4's completely new build system). (Mmm 
GLEP 33...)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951