| 1 |
On Wed, Dec 11, 2013 at 2:41 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> Very limited usefulness, a lot of extra complexity. We'd rather work on |
| 3 |
> making eclasses simpler. |
| 4 |
|
| 5 |
Sorry to beat a potentially dead horse, but many days later, I still |
| 6 |
can't bring myself to agree with this, at least, not with respect to |
| 7 |
src_compile. |
| 8 |
|
| 9 |
The patch to the eclass is trivial and easily understood. The |
| 10 |
MULTILIB_PARALLEL_PHASES interface seems intuitive, just name the |
| 11 |
phases you want parallel-ized in the string... Where's the |
| 12 |
complexity? |
| 13 |
|
| 14 |
If end-users would rather not risk it, they can set MAKEOPTS=-j1. If |
| 15 |
ebuild authors suspect that their particular ebuilds will have |
| 16 |
parallel build problems, they can simply do nothing, and their |
| 17 |
multilib-minimal-based ebuild would be non-abi-parallel. It all seems |
| 18 |
pretty reasonable to me. |
| 19 |
|
| 20 |
As for usefulness -- if someone wants to sit around and wait for three |
| 21 |
dev-qt/qtwebkit compiles in a row to complete, one-at-a-time, then I |
| 22 |
guess it's not useful to them. Personally, it'd be useful to me. I |
| 23 |
can't imagine I'm the only person who feels that way. |
| 24 |
|
| 25 |
-gmt |
Archives