On Tue, 10 Oct 2006 18:16:16 -0700 Brian Harring <[EMAIL PROTECTED]> 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 -- [email protected] mailing list
