Date: Fri, 13 Apr 2007 16:51:33 -0700 (PDT) From: youshi10@u.washington.edu To: freebsd-ports@freebsd.org Subject: Re: parallel builds revisited Message-ID: <Pine.LNX.4.43.0704131651330.27171@hymn09.u.washington.edu> In-Reply-To: <20070413154354.GP27736@potato.chello.upc.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Apr 2007, David Ne=C4=8Das (Yeti) wrote: > On Fri, Apr 13, 2007 at 05:10:47PM +0200, Pav Lucistnik wrote: >> Peter Pentchev p=C3=AD=C5=A1e v p=C3=A1 13. 04. 2007 v 18:06 +0300: >>> > >>> > I was thinking about having it embedded in every port's Makefile >>> > directly, instead. Something like >>> > >>> > USE_MAKE_JOBS=3D=092 >>> >>> IMHO, hardcoding the number of jobs in the port's Makefile would not >>> be the best approach. I think a port should only flag whether it >>> supports parallel building at all or not - and leave the number of jobs >>> to either the ports framework or the administrator's choice. >> >> That was just an example. You can do >> >> USE_MAKE_JOBS=3D=09yes >> >> for autoscaling perfectly well. For details, see the patch I linked. > > The patch gives no reason for such hardcoding, it just > implements it. How many ports exist that can fail with N+1 > jobs yet cannot break with N jobs (for N > 1)? > > Yeti > > -- > http://gwyddion.net/ My opinion is that there should be a threshold value empirically derived by= the developer / retrieved by bug reports, as well as a knob, to specify th= e maximum number of parallel jobs to be used for a particular port, that wa= y you don't get people accidentally specifying, say 10 jobs when it can onl= y handle 2-3. Doing that should decrease the amount of time people have to spend fishing = through bug reports for minute information, and decrease the failure encoun= tered by end users going all out trying to run as many jobs as possible on = a given port. -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.43.0704131651330.27171>