Re: [gentoo-portage-dev] Max parallelization setting

[Brian Harring]

On Tue, Oct 10, 2006 at 03:20:55AM -0700, Zac Medico wrote:
> Brian Harring wrote:
> > I might be daft (likely), but why not just introduce a var indicating
> > max parallelization instead?  Tweak portage to push that setting into
> > MAKEOPTS="${MAKEOPTS+${MAKEOPTS} } -j${PARALLELIZATION}".
>
> The idea sounds good, but I'm not clear on all the details.  It
> seems like there are several distinct parts:
>
> 1) Ebuild maintainter sets a metadata variable to indicate the level
> of parallelization possible in a build.

RESTRICT moreso indicating if it's parallelizable or not.

> 2) Gentoo user sets a configuration option indicating the maximum
> level of parallelization spread across multiple builds at a given time.


> 3) Package manager uses the user's config to allocate an appropriate
> PARALLELIZATION at build time, based on 1 and 2 above.  Then the
> src_compile() function of the ebuild translates PARALLELIZATION into
> the appropriate build system flags (possibly with the help of an
> eclass function).

Not necessarily src_compile, but close enough; the details of how 
MAX_PARALLELIZATION gets shoved in is semi package specific, although 
it's kind of implicit at this point that -j# for MAKEOPTS would likely 
be directly fooled with.

For other build systems, rely on eclasses handling it; for MAKEOPTS, 
would be preferable to do the same imo, but that's not an easy 
transition.

Mind you since there isn't a way to adjust the allowed slices 
(essentially) while a compile is underway, this won't hit 100% 
utilization- further, src_install still abides by MAKEOPTS, but it's 
not like -jN is going to help much there.

That said, it's better then the current crapshoot required for trying 
to do parallel builds; either you have to monkey patch make.conf 
everytime, or try env overrides for it, both of which aren't 
incredibly friendly/simple if you're just trying to do an upgrade that 
abuses your duo/quad.
~harring