Gentoo Archives: gentoo-dev

From: "Michał Górny" <gentoo@××××××××××.pl>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: New eclass: scons.eclass
Date: Mon, 23 Aug 2010 15:12:37
Message-Id: 20100823171147.24c6e015@pomiocik.lan
In Reply to: Re: [gentoo-dev] Re: New eclass: scons.eclass by Maciej Mrozowski
On Sun, 22 Aug 2010 23:03:44 +0200
Maciej Mrozowski <reavertm@×××××.com> wrote:

> I'd suggest providing all src_* phases except src_unpack.
Providing a blank src_configure() would be fine but...
> Even src_prepare that calls base_src_prepare - to get PATCHES and > epatch_user support - for simplicity requiring EAPI-2 as providing > src_unpack in buildsystem eclasses is a bad design (like providing > src_prepare in scm eclasses - this one is yet to be fixed).
Why would I do that? If an ebuild needs to use base_src_prepare(), why can't it simply inherit the base eclass? Nothing buildsystem-specific needs to be done in src_prepare() here. And requiring EAPI=2 is even more pointless as SCons doesn't mostly distinguish between 'configure' and 'build' phases.
> Also calling base_src_install in scons_src_install if possible would > be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils, > autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses.
Even more pointless. Although we can assume many of the SConstruct files use the name 'install' for their 'install' target, we can't do that for 'DESTDIR' or how a particular project calls it. Not to mention some don't provide such a thing at all. Every SCons-based ebuild should redefine src_install(). -- Best regards, Michał Górny <> <xmpp:mgorny@××××××.ru>


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] Re: New eclass: scons.eclass Maciej Mrozowski <reavertm@×××××.com>