Re: make -j in Debian packages
On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> On Wed, 28 Jun 2006, Adam Borowski wrote:
> > Let's allow maintainers to use make -jX according to their common
> > sense, requiring obeying an env variable to opt out.
>
> Why not just have some ENV variable (CONCURRENCY_LEVEL?) which
> specifies the maximum -j; the package maintainer is free to choose any
> level equal to or below that.
>
> If CONCURRENCY_LEVEL is not set, the rules file must assume
> CONCURRENCY_LEVEL=1 (or not specify -j?); this will keep what should
> be the current status quo the same, and allow buildd's and other
> builders to set this variable to a reasonable level for their system.
I would rather have it default to "a reasonable value on an average
uniprocessor box, according to the maintainer's common sense".
Otherwise, nearly no one will have this variable set and thus the
whole benefit will be lost. And cutting the build time by half or
more is a GREAT thing to have.
> (or not specify -j?)
no -j => 1
-j with no value => INFINITY
This is certainly not what you want for a package build; unlimited -j
is useful for other uses of make.
-jX (or -j X, the space is BAD for an option with an optional
argument) => X processes
> This has the disadvantage of not automatically using -j for every
> package and requiring maintainer buy in to see results... but
> presumably those packages where it actually makes a difference will
> adopt it just so maintainer builds don't take as long.
Why would you restrict this just to maintainer builds? Speeding up
buildds and user builds would be a worthy goal, too. An obscure env
var hardly anyone knows about means that hardly anyone will be
affected.
The m68k buildd admins are here, listening, so they can add this
line.
Or, another approach:
if CONCURRENCY_LEVEL is unset, debian/rules can check the amount of
memory present and/or the number of CPUs and make a guess.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: