1 |
Ryan Hill wrote: |
2 |
> Zac Medico wrote: |
3 |
>> Funtoo has support for FEATURES=localpatch, which does the epatch_user |
4 |
>> thing before src_prepare. I think it should really go after src_prepare, |
5 |
>> in order to apply patches after those that src_prepare may apply |
6 |
>> (avoiding possible conflicts). |
7 |
> |
8 |
> I agree. |
9 |
> |
10 |
>> The reason that Funtoo's FEATURES=localpatch applies patches before |
11 |
>> src_prepare is that it's common for eautoreconf to be called inside |
12 |
>> src_prepare, and applying patches after src_prepare can create a need to |
13 |
>> call eautoreconf a second time. |
14 |
> |
15 |
> Well that could waste a bit of time but is pretty much harmless, no? And |
16 |
> the existing usages of epatch_user (other than autotools-utils) don't |
17 |
> eautoreconf anyways, nor should they in case the package doesn't use |
18 |
> autotools. |
19 |
> |
20 |
Zac Medico wrote: |
21 |
> The nice thing about delegating the epatch_user call to the ebuild/eclass |
22 |
> is that it allows the epatch_user call be positioned directly before an |
23 |
> eautoreconf call when appropriate. |
24 |
|
25 |
It seems there's two major cases, with autotools or without. In either case, |
26 |
epatch_user should be called after Gentoo patches have been applied. |
27 |
|
28 |
Why not make epatch_user set a variable to indicate that patches have been |
29 |
applied, and only apply the patches on the first call? |
30 |
|
31 |
Then eautoreconf could call it before calling autoconf (and the ebuild |
32 |
wouldn't need to worry about it.) And any custom src_prepare function could |
33 |
call it when needed, if it needed to be done during the phase, and not |
34 |
after. |
35 |
|
36 |
After src_prepare, the PM could just call it unconditionally, since it will |
37 |
not apply the patches again, if it's already been called by the ebuild. |
38 |
|
39 |
Does that make sense? |
40 |
Steve. |
41 |
-- |
42 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |