From owner-freebsd-ports@FreeBSD.ORG Thu Apr 2 05:17:42 2009 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F804106568A for ; Thu, 2 Apr 2009 05:17:42 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 12B508FC13 for ; Thu, 2 Apr 2009 05:17:42 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-20-240-188.phil.east.verizon.net [70.20.240.188]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id E4D3E718CC; Thu, 2 Apr 2009 14:17:38 +0900 (JST) Date: Thu, 2 Apr 2009 01:17:27 -0400 From: Yoshihiro Ota To: Coleman Kane Message-Id: <20090402011727.2c718f5d.ota@j.email.ne.jp> In-Reply-To: <1238000271.2543.42.camel@localhost> References: <1237901632.1849.19.camel@pav.hide.vol.cz> <49C8EE21.3080702@gmail.com> <1237906449.1849.25.camel@pav.hide.vol.cz> <1237906705.1741.13.camel@localhost> <1237907945.1849.27.camel@pav.hide.vol.cz> <1237912100.1741.16.camel@localhost> <1237912382.1849.35.camel@pav.hide.vol.cz> <20090325163050.GD32386@hades.panopticon> <1238000271.2543.42.camel@localhost> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, Pav Lucistnik , Niclas Zeising , Dmitry Marakasov Subject: Re: HEADS UP multi processor compilations for everyone X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 05:17:42 -0000 On Wed, 25 Mar 2009 12:57:51 -0400 Coleman Kane wrote: > On Wed, 2009-03-25 at 19:30 +0300, Dmitry Marakasov wrote: > > * Pav Lucistnik (pav@FreeBSD.org) wrote: > > > > > > > This would break very fast -- it's passing -j3 to port Makefile instead > > > > > of vendor Makefile. > > > > > > > > This has worked fine for me for countless years, except where the > > > > vendor's Makefiles were not parallel-safe. This has been my trick to get > > > > larger things (like mysql or xorg-server) to make in parallel. It *did* > > > > work. If this has changed, then it definitely warrants mention in > > > > UPDATING. > > > > > > Then it must have worked all these years by pure chance :) > > > > Be the way, could anyone clarify how this works? My idea was that > > passing -j to port Makefile does nothing, as make/gmake on vendor's > > Makefile is ran without any -j flags -> you get usual singlethreaded > > build. However, I have a broken port, which uses gmake and something > > like that: > > > > sometarget: > > (cd xxx; make) > > > > and that fails with -j (make: illegal option -- -). So is there > > some magic with recursive make calls and -j? > > > > When processing a Makefile, make's that support concurrent operation > look for targets that will execute the $(MAKE) program. Whenever a > compliant make is run (make or gmake), if it detects $(MAKE) in a rule > then it will automatically expand that rule into a child process that > has some sort of magical connection to the parent process. The > connection allows the different make processes to share the same pool of > "process count" resources amongst each other. > > I am not sure what the implementation is, but this communication > mechanism allows child "make" processes called with "$(MAKE) ..." from > inside a Makefile to globally only use N children (from -j N), and > otherwise block until more "free jobs" are available amongst their > shared job pool. > > I hope that's clear... Probably more so than the explanation given on > GNU make's manual. > > -- > Coleman Kane > Indeed, that is why (cd xxx; make) fails where gmake is running this command. The way GNU make and BSD make passes -j related options are different. They are not compatible. If I remember correctly, if GNU make calls BSD make (which is an error of writing Makefiles in most of vendor codes), the differences are significant and fails. Usually, changing "make" to "$(MAKE)" fixes the problems. Why did it build when "-j" was not supplied. That is because makefile rule was not GNU makefile specific such that BSD make could also executed it without problems. With "-j" switch presented, these two "make" commands became incompatible each other. I hope this helps if you guys haven't found this facts; I hope I had replied earlier. Regards, Hiro