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