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
pgpaiG8rxHKRN.pgp
Description: PGP signature
