Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)

[Brian Harring <ferringb@gmail.com>]

On Fri, Aug 31, 2012 at 11:12:44AM -0400, Alexis Ballier wrote:
> On Fri, 31 Aug 2012 15:45:21 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> > On Fri, 31 Aug 2012 10:21:15 +0200
> > Ulrich Mueller <ulm@gentoo.org> 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?
> 
> How can this work ? I cant think of any simple solution.
> 
> > 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?
> 
> IMHO EAPI-5 compliant PMs should do MAKEOPTS="$MAKEOPTS -j$EJOBS" for
> every EAPI; using EJOBS from ebuilds/eclasses is allowed only in EAPI 5
> and greater.
> This is retroactive but could be classified 'PM internals' so its fine
> imho.

This approach is fine imo, although I'd *potentially* look at adding a 
magic $PROC_COUNT var that is the # of cpu threads on the system; 
either that or defaulting jobs to it.

I rather dislike requiring users to go jam a 2/4/8 in there when it's 
easy to compute.  That said, it's minor.

Either way, yes, I think EJOBS should be in EAPI5.
~harring