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
pgpZKzky1JHbB.pgp
Description: PGP signature
