List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sun, 22 Aug 2010 23:03:44 +0200
Maciej Mrozowski <reavertm@...> 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