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

[Marius Mauch]

On Tue, 10 Oct 2006 18:16:16 -0700
Brian Harring <ferringb@×××××.com> wrote:

> Say I've got a 32x system; I screw up and have -j32 in my makeopts,
> and PARALLELIZATION=32.

So you screwed up ... You can do that already ;)

> Now either the pkg manager needs to understand MAKEOPTS (beyond just
> adding a simple string to it), and check for -j*, or it's going to
> wind up allowing 32 seperate build jobs, each with -j32.

Is PARALLELIZATIOn the big global var or the low level var for the number of parallel merges? I didn't mean to merge those two.

> Personally, I *really* would love to see that loadavg (that would be
> one nifty screenshot).

Depends on the value of -l* ;)

> Allowing MAKEOPTS to override the alloted build slices  the manager
> hands it totally defeats the purpose of moving the parallelization
> factor into a seperate var; the intention is to give the manager a
> max, and allow it to allocate as it needs depending on the # of build
> jobs that can be ran at that point.

You misunderstood: I meant that one could either define the parallelization on the super-high level and hope that the pkgmanager does the best with it or define the different settings manually. It's up to the user which one he wants.

> Response of course is "don't have -j* in your MAKEOPTS"; well dar,
> thus why allow it? ;)

No, reponse is "use -l* in MAKEOPTS" ;)

Just in case your wondering about the reasons why I want to keep the alternative of low-level vars:
a) not all build systems are equal (efficiency, stability, flexibility), so one might want to have different settings for them
b) generally only src_compile (the actual build) is cpu-bound, the other phases are generally IO-bound so it makes sense to have separate vars for them in some cases
c) debugging/analyzing/testing

Marius
-- 
gentoo-portage-dev@g.o mailing list