| 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> |
Archives