1 |
On Mon, 23 Aug 2010 19:27:22 -0400 |
2 |
Mike Frysinger <vapier@g.o> wrote: |
3 |
|
4 |
> then keep it simple and separate: |
5 |
> escons() { |
6 |
> debug-print-function ${FUNCNAME} "${@}" |
7 |
> |
8 |
> set -- scons $(scons_clean_makeopts) ${SCONSOPTS} |
9 |
> ${EXTRA_ESCONS} "${@}" echo "${@}" >&2 |
10 |
> "${@}" |
11 |
> } |
12 |
> |
13 |
> now you dont have to worry about changes between invocations and the |
14 |
> developer has a clear path -- if they need to force a serial build |
15 |
> for example, they can either append MAKEOPTS, SCONSOPTS, or pass it |
16 |
> straight to escons. no cache confusion or desync between the vars. |
17 |
|
18 |
Ok, but will use ${SCONSOPTS-$(scons_clean_makeopts)} instead. |
19 |
The point is that the user can decide to have different SCONSOPTS set |
20 |
in his/her make.conf, and he/she couldn't magically drop MAKEOPTS for |
21 |
SCons ebuilds then. |
22 |
|
23 |
Additionally, I will implement the cache in scons_clean_makeopts(). |
24 |
That should work just fine. |
25 |
|
26 |
-- |
27 |
Best regards, |
28 |
Michał Górny |
29 |
|
30 |
<http://mgorny.alt.pl> |
31 |
<xmpp:mgorny@××××××.ru> |