| 1 |
On Tue, 19 Aug 2008 21:27:03 +0100 |
| 2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
| 3 |
|
| 4 |
> Ciaran McCreesh wrote: |
| 5 |
|
| 6 |
> >> b) Does it really matter? |
| 7 |
> > |
| 8 |
> > In the grand scheme of things, no. In the grand scheme of things, |
| 9 |
> > you only *need* a single src_ function. From a maintainer |
| 10 |
> > convenience perspective, however, src_prepare is marginally more |
| 11 |
> > useful than having a split src_configure. |
| 12 |
> > |
| 13 |
> How so? |
| 14 |
> |
| 15 |
> From a user point of view, and from a maintenance point of view, |
| 16 |
> src_configure is very useful. |
| 17 |
|
| 18 |
As a maintainer I would find it very useful to be able to do `ebuild |
| 19 |
foo-1.ebuild <phase>` to get the build dir into following states: |
| 20 |
|
| 21 |
a) pristine source (unpack) |
| 22 |
b) patched, seded, eautoreconf'd, or |
| 23 |
everything-else-we're-doing-in-src_unpack-right-now'd (prepare) |
| 24 |
c) ./configured (configure) |
| 25 |
d) compiled (compile) |
| 26 |
|
| 27 |
the state between a) and b) is very useful as anyone who has |
| 28 |
gone back and forth commenting and uncommenting epatch/eautoreconf lines |
| 29 |
in src_unpack (ie. everyone) can attest. between c) and d) would be |
| 30 |
less useful for me but still quite welcome. |
| 31 |
|
| 32 |
|
| 33 |
-- |
| 34 |
gcc-porting, by design, by neglect |
| 35 |
treecleaner, for a fact or just for effect |
| 36 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |
Archives