Gentoo Archives: gentoo-dev

From: Maciej Mrozowski <reavertm@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: New eclass: scons.eclass
Date: Mon, 23 Aug 2010 17:37:05
In Reply to: Re: [gentoo-dev] Re: New eclass: scons.eclass by "Michał Górny"
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@×××××.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.
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 ignore. 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 phases). What I hate is deliberately introduced inconsistency in ebuild API's. -- regards MM


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


Subject Author
Re: [gentoo-dev] New eclass: scons.eclass "Michał Górny" <gentoo@××××××××××.pl>