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 Monday 23 of August 2010 17:11:47 Michał Górny wrote:
> 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.
Because if you're to provide src_prepare, for EAPI<2 you need to provide
src_unpack as well but it's wrong in buildsystem eclasses as I already pointed
out (since src_unpack:EAPI1 -> src_unpack:EAPI2 + src_prepare:EAPI2), and
requiring EAPI-2 allows you to avoid it.
If you don't care for PATCHES or user_patches and hence compliance with other
buildsystem eclasses, feel free.
> > 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().
Like I said, if you don't care for consistency with the rest, feel free to
If SCons is unpredictable, then don't provide *any* phases and only functions
and rename it to scons-utils to match its purpose (we're quite likely planning
to rename cmake-utils.eclass to cmake.eclass for said consistency,
unfortunately it was introduced in first place with such name and provided
What I hate is deliberately introduced inconsistency in ebuild API's.
signature.asc (This is a digitally signed message part.)