1 |
On Sun, 22 Aug 2010 23:03:44 +0200 |
2 |
Maciej Mrozowski <reavertm@×××××.com> wrote: |
3 |
|
4 |
> I'd suggest providing all src_* phases except src_unpack. |
5 |
|
6 |
Providing a blank src_configure() would be fine but... |
7 |
|
8 |
> Even src_prepare that calls base_src_prepare - to get PATCHES and |
9 |
> epatch_user support - for simplicity requiring EAPI-2 as providing |
10 |
> src_unpack in buildsystem eclasses is a bad design (like providing |
11 |
> src_prepare in scm eclasses - this one is yet to be fixed). |
12 |
|
13 |
Why would I do that? If an ebuild needs to use base_src_prepare(), why |
14 |
can't it simply inherit the base eclass? Nothing buildsystem-specific |
15 |
needs to be done in src_prepare() here. |
16 |
|
17 |
And requiring EAPI=2 is even more pointless as SCons doesn't mostly |
18 |
distinguish between 'configure' and 'build' phases. |
19 |
|
20 |
> Also calling base_src_install in scons_src_install if possible would |
21 |
> be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils, |
22 |
> autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses. |
23 |
|
24 |
Even more pointless. Although we can assume many of the SConstruct |
25 |
files use the name 'install' for their 'install' target, we can't do |
26 |
that for 'DESTDIR' or how a particular project calls it. Not to mention |
27 |
some don't provide such a thing at all. Every SCons-based ebuild should |
28 |
redefine src_install(). |
29 |
|
30 |
-- |
31 |
Best regards, |
32 |
Michał Górny |
33 |
|
34 |
<http://mgorny.alt.pl> |
35 |
<xmpp:mgorny@××××××.ru> |