Justin posted on Wed, 14 Apr 2010 08:46:15 +0200 as excerpted:

> On 14/04/10 04:12, Zac Medico wrote:
>> Hi everyone,
>> 
>> Should we add a RESTRICT=parallel value for ebuilds that can't be built
>> at the same time as other ebuilds? Brian says we need it for things
>> like xorg-server which calls eselect opengl.
> 
> There is at least one other example which benefits from singlular build,
> atlas libs. They run a benchmark suite to create platform specific
> headers, which is heavily influenced by the system load. So having
> RESTRICT=parallel would make the emerge more reliable.

sci-libs/blas-atlas (and perhaps lapack-atlas, etc, too), right?  
"Automatically tuned..."

Wow!  Yeah, that sounds like a reasonable example.  Sort of like the 
kernel does for md/RAID-5 and 6 at boot, I'd guess, choosing the fastest 
algorithm on the platform, only they're doing it during system runtime 
when who /knows/ what else is running!  Having a second highly 
parallelizable (MAKEOPTS version) build go from config to build and its 
load go from say .8 to 8. in the middle of those benchmarks /could/ screw 
things up "just a little!"

Thanks.  That's just the sort of additional practical example I was asking 
for to try to get my mind around this.  Excellent example as, unlike the 
various xorg/mesa/drivers thing, it's pretty hard to argue "just code 
around it", for this one.  The only technical way out of it here would 
seem to be to change the build-and-benchmark strategy itself, which would 
rather defeat the "automatically tuned" bit entirely.

BTW, gcc seems to do some stage output comparing in its bootstrap 
process.  Is that all absolute code correctness, or is there some 
performance benchmarking there that could benefit from this as well?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman