From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 10:24:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 337DC16A4CE; Fri, 12 Nov 2004 10:24:28 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F7E043D2F; Fri, 12 Nov 2004 10:24:27 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) iACAO4U373504; Fri, 12 Nov 2004 11:24:05 +0100 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) iACAO4I360724; Fri, 12 Nov 2004 11:24:04 +0100 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id iACAObu25331; Fri, 12 Nov 2004 11:24:37 +0100 (MET) Date: Fri, 12 Nov 2004 11:24:12 +0100 (CET) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Poul-Henning Kamp In-Reply-To: <95167.1100254152@critter.freebsd.dk> Message-ID: <20041112111357.T42945@beagle.kn.op.dlr.de> References: <95167.1100254152@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: [TEST] make -j patch [take 2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 10:24:28 -0000 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