On Fri, 12 Nov 2004, Poul-Henning Kamp wrote: PK>In message <20041112105437.T42945_at_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_at_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. hartiReceived on Fri Nov 12 2004 - 09:24:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:22 UTC