On Saturday 02 July 2005 14:41, Gregorio Guidi wrote: > I'm back from a trip and I'm slowly catching up with all the mails on this > topic, but a couple of things come to my mind ... please bear with me. > > 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.
I completely agree. > As many already pointed out, using something like > DEPEND="$(qt_min_version 3.1)" > is very ugly, so we should use it only if it is really unavoidable. I agree too, but I haven't seen yet how it can be avoided. > An application based on Qt4 should look just like this: > > inherit qt4 > > HOMEPAGE=... > SRC_URI=... > ... > > the qt4 eclass would automatically add a DEPEND="=x11-libs/qt-4*", and > would provide default src_compile(), src_install()... That's fine, except I would think that very few ebuilds would be able to make use of a default src_compile() and src_install(). It works for the kde eclass because most of the kde packages are built using the standard kde auto* scripts, but I doubt many qt only packages have the same build structure. [snip] While your proposal works okay for the qt4 scenario, I'm more concerned with the existing qt3 at the moment. As is, I stil l don't see a way around what has been proposed for those ebuilds. Until portage has the ability to handle && deps, I fear there's no real way around it. I don't think we'll have time to wait much longer; I expect ebuilds that need qt4 will start appearing in portage soon and the minute that qt4 is marked ~arch it instantly creates the dependency mess addressed previously. -- gentoo-dev@gentoo.org mailing list
