Date: Fri, 12 Nov 2004 11:24:12 +0100 (CET) From: Harti Brandt <harti@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: current@freebsd.org Subject: Re: [TEST] make -j patch [take 2] Message-ID: <20041112111357.T42945@beagle.kn.op.dlr.de> In-Reply-To: <95167.1100254152@critter.freebsd.dk> References: <95167.1100254152@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Nov 2004, Poul-Henning Kamp wrote: PK>In message <20041112105437.T42945@beagle.kn.op.dlr.de>, Harti Brandt writes: PK>>On Fri, 12 Nov 2004, Poul-Henning Kamp wrote: PK>> PK>>PK>In message <20041112090905.GD41844@ip.net.ua>, Ruslan Ermilov writes: PK>>PK> PK>>PK>>But you don't give an opportunity to control this on a sub-make PK>>PK>>level (that's what I ask for). PK>>PK> PK>>PK>Why would that be of any use ? If you run "make universe" the task PK>>PK>at hand is to get "make universe" to complete. You should not care PK>>PK>which partcular submake starts how many jobs when, you should only PK>>PK>care that it works as efficient as possible. PK>> PK>>A new make is not necessarily a sub-make in the sense as started by PK>>$(MAKE). A make could also be started by, for example, an awk script or PK>>whatever running from make and who's task has not directly to do with the PK>>top make's task. Something like: PK> PK>And this will get correctly detected as long as the environment PK>variable gets passed to the submake. PK> PK>>I'm not sure whether automatically putting the make started by portinstall PK>>into the same group of makes as the top make is what one wants in such PK>>cases. PK> PK>Can you explain just why you think it would be beneficial to have PK>less control with the total load ? It would actually give me _more_ control over make's behaviour. I could, for example, build the tool with -j4, but run the tool with -j2. Suppose that is a long running regression test that I don't want to occupy my 4 processor machine, but I want the tool for the test to build fast. As a side note: The MAKEFLAGS variable has the same problem. If I specify -n on the command line, it gets passed down to each and every make that is started. This may or may not be the behaviour I actually want, but the documentation of MAKEFLAGS makes me at least aware of that fact and lets me control that aspect. This way I may patch out -n from MAKEFLAGS before starting something that may start another make I want to execute its commands in any case. I think, that putting the environment variable into the man page would just do the job. I must admit, that I was somewhat surprised when I tested the patches that removed the remote make stuff to see that with -j4 I sometimes got 12 or more gccs. Your patch is actually very nice. harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041112111357.T42945>