Date: Thu, 2 Apr 2009 01:17:27 -0400 From: Yoshihiro Ota <ota@j.email.ne.jp> To: Coleman Kane <cokane@FreeBSD.org> Cc: ports@FreeBSD.org, Pav Lucistnik <pav@FreeBSD.org>, Niclas Zeising <niclas.zeising@gmail.com>, Dmitry Marakasov <amdmi3@amdmi3.ru> Subject: Re: HEADS UP multi processor compilations for everyone 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Mar 2009 12:57:51 -0400 Coleman Kane <cokane@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090402011727.2c718f5d.ota>