1 |
On Wed, 14 Apr 2010 08:46:15 +0200 Justin <jlec@g.o> wrote: |
2 |
|
3 |
> There is at least one other example which benefits from singlular |
4 |
> build, atlas libs. They run a benchmark suite to create platform |
5 |
> specific headers, which is heavily influenced by the system load. So |
6 |
> having RESTRICT=parallel would make the emerge more reliable. |
7 |
|
8 |
And that's another example of working around broken ideas. There is |
9 |
an uncountable number of possibilities of many different factors |
10 |
affecting the system load, and thus the results of the benchmark. |
11 |
Removing one of them would indeed help in many cases but in many other |
12 |
it wouldn't make any difference, additionally slowing down the whole |
13 |
system update process. |
14 |
|
15 |
Please notice that in order to implement that correctly, emerge would |
16 |
have to wait until all previously running emerges are done, and avoid |
17 |
running further ones while the build process is running. While |
18 |
in the case of xorg-server, the 'lock' is needed throughout the whole |
19 |
build process, in your case it is needed only for a short amount |
20 |
of time when the benchmark is being performed --- and the 'real' part |
21 |
of building would unnecessarily block emerge. |
22 |
|
23 |
If this is ever to be implemented, it totally needs to be |
24 |
user-overridable. Else, we'll end up someday like Windows, forcing user |
25 |
to reboot the system and perform the merge on a dedicated runlevel. |
26 |
|
27 |
-- |
28 |
Best regards, |
29 |
Michał Górny |
30 |
|
31 |
<http://mgorny.alt.pl> |
32 |
<xmpp:mgorny@××××××.ru> |