On Fri, 2012-08-31 at 15:45 +0100, Ciaran McCreesh wrote: > On Fri, 31 Aug 2012 10:21:15 +0200 > Ulrich Mueller <[email protected]> wrote: > > Coming back to this old topic [1]. Is there still consensus that we > > should have such an EJOBS variable? (It shouldn't be called JOBS > > because this name is too generic, see the old discussion.) Then we > > could add it to EAPI 5. > > > > Ulrich > > > > [1] > > <http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml> > > If we're doing this, do we tell users to stop setting MAKEOPTS for > EAPIs 5 and greater? Do we change the name of MAKEOPTS for EAPIs 5 and > greater instead? Do we put fancy code in the package mangler to deal > with it?
Users typically set MAKEOPTS systemwide in /etc/make.conf. If EJOBS will have no effect for <EAPI5 ebuilds, then obviously we should not be advising users to stop using MAKEOPTS until the whole tree has migrated to EAPI5. And if EJOBS will be recognized by a future version of portage for all EAPIs, then we still should allow MAKEOPTS because some users may want to use --load-average. Changing the name of MAKEOPTS in >=EAPI5 makes no sense. First, because it's a standard environment variable used by gnu make. Second, because having 3 different settings for parallel building (EJOBS, MAKEOPTS, and "MAKEOPTS_EAPI5") would be insane. Fancy code in the package manager would be the way to go IMHO. Ulrich's message contains a reasonable description of the algorithm. -Alexandre.
signature.asc
Description: This is a digitally signed message part
