On Wed, 2009-03-25 at 19:30 +0300, Dmitry Marakasov wrote: > * Pav Lucistnik (p...@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
signature.asc
Description: This is a digitally signed message part
