HEADS UP multi processor compilations for everyone

Coleman Kane cokane at FreeBSD.org
Wed Mar 25 09:59:23 PDT 2009


On Wed, 2009-03-25 at 19:30 +0300, Dmitry Marakasov wrote:
> * Pav Lucistnik (pav at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20090325/b6c5e2e3/attachment.pgp


More information about the freebsd-ports mailing list