Date: Sun, 26 Nov 2006 15:04:38 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: John Birrell <jb@what-creek.com> Cc: arch@freebsd.org Subject: Re: Proposed change to make -j Message-ID: <20061126120437.GA60959@comp.chem.msu.su> In-Reply-To: <20061123232035.GA56985@what-creek.com> References: <20061123232035.GA56985@what-creek.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 23, 2006 at 11:20:35PM +0000, John Birrell wrote: > Currently 'make -j' reports an error if the number of jobs > isn't specified. > > I'd like to change make(1) to treat -j (without a number) as > meaning "set the number of jobs to the number of processors". > > On sun4v, each processor isn't too powerful and system performance > is only decent when you use all the processors - 32 in my case. > > I've been working on a parallel 'make release' process which > would benefit from having -j set by default. At the moment I > set MAKEFLAGS=j32 in my environment and this achieves the desired > result, but -j would be more general. > > Thoughts? Besides the portability issues already pointed at, making option's argument optional itself doesn't fit in the getopt(3) semantics and is confusing. As a rule, option's argument must be able to begin with a dash. If this extension to make(1) were good from the technical POV, I'd suggest "-j -1", "-j max", "-j ncpu", or whatever, but not a bare "-j". Even if the make(1) code can handle such optional arguments, other stock tools should not be spoiled by that. IMHO :-) -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061126120437.GA60959>