On Sun, 22 Aug 2010 23:03:44 +0200 Maciej Mrozowski <[email protected]> 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 <http://mgorny.alt.pl> <xmpp:[email protected]>
signature.asc
Description: PGP signature
