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
Message-Id: 201008231936.50607.reavertm@gmail.com
In Reply to: Re: [gentoo-dev] Re: New eclass: scons.eclass by "Michał Górny"
1 On Monday 23 of August 2010 17:11:47 Michał Górny wrote:
2 > On Sun, 22 Aug 2010 23:03:44 +0200
3 >
4 > Maciej Mrozowski <reavertm@×××××.com> wrote:
5 > > I'd suggest providing all src_* phases except src_unpack.
6 >
7 > Providing a blank src_configure() would be fine but...
8 >
9 > > Even src_prepare that calls base_src_prepare - to get PATCHES and
10 > > epatch_user support - for simplicity requiring EAPI-2 as providing
11 > > src_unpack in buildsystem eclasses is a bad design (like providing
12 > > src_prepare in scm eclasses - this one is yet to be fixed).
13 >
14 > Why would I do that? If an ebuild needs to use base_src_prepare(), why
15 > can't it simply inherit the base eclass? Nothing buildsystem-specific
16 > needs to be done in src_prepare() here.
17 > And requiring EAPI=2 is even more pointless as SCons doesn't mostly
18 > distinguish between 'configure' and 'build' phases.
19
20 Because if you're to provide src_prepare, for EAPI<2 you need to provide
21 src_unpack as well but it's wrong in buildsystem eclasses as I already pointed
22 out (since src_unpack:EAPI1 -> src_unpack:EAPI2 + src_prepare:EAPI2), and
23 requiring EAPI-2 allows you to avoid it.
24 If you don't care for PATCHES or user_patches and hence compliance with other
25 buildsystem eclasses, feel free.
26
27 > > Also calling base_src_install in scons_src_install if possible would
28 > > be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils,
29 > > autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses.
30 >
31 > Even more pointless. Although we can assume many of the SConstruct
32 > files use the name 'install' for their 'install' target, we can't do
33 > that for 'DESTDIR' or how a particular project calls it. Not to mention
34 > some don't provide such a thing at all. Every SCons-based ebuild should
35 > redefine src_install().
36
37 Like I said, if you don't care for consistency with the rest, feel free to
38 ignore.
39 If SCons is unpredictable, then don't provide *any* phases and only functions
40 and rename it to scons-utils to match its purpose (we're quite likely planning
41 to rename cmake-utils.eclass to cmake.eclass for said consistency,
42 unfortunately it was introduced in first place with such name and provided
43 phases).
44 What I hate is deliberately introduced inconsistency in ebuild API's.
45
46 --
47 regards
48 MM

Attachments

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

Replies

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