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 |