Il 04/09/2012 19:15, Zac Medico ha scritto:
On 09/04/2012 04:00 AM, Walter Dnes wrote:
On Sat, Sep 01, 2012 at 05:20:02PM -0700, Brian Harring wrote
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.
One question about the suggested EJOBS variable; will it over-ride
MAKEOPTS? Every so often on the Gentoo-user list, someone comes along
with a mysterious build failure. The first suggestion is to reset
MAKEOPTS to -j1. And on some occasions, that is indeed the solution to
the mysterious build failure.
That would be due to a missing dependency in the Makefiles, and using
-j1 is just a workaround. The ebuild can be hardcoded to use emake -j1
until the Makefile gets fixed.
I set -j1 and leave it that way. Yes, the builds take longer, but the
resulting binary is just as fast. And the amount of time I "save" will
be blown away the first time I end up screwing around a couple of hours
trying to fix a mysterious build failure. That's why I want the user to
have the option of over-riding EJOBS, should it ever be implemented.
You could use EXTRA_EMAKE for that. You can do per-package settings via
/etc/portage/package.env.
Dunno where to place this request, but if we go for something like EJOBS
could we also make it phase specific?
So compile, install and test could have a different number of jobs running.
Possibly three different variables that override a predefined EJOBS.
TIA
