On Fri, 2012-07-06 at 22:36 +0200, Reinier Post wrote: > On Fri, Jul 06, 2012 at 03:19:11PM +0000, Jason Merrill wrote: > > [...] > > > I note that patch #5108 seems to create a single global mutex, whereas the > > documentation for the SCO .MUTEX target suggests that each occurrence of > > .MUTEX creates a separate mutex, so that given > > > > .MUTEX: this that > > .MUTEX: yours mine > > Yikes - isn't make complicated enough? > > Isn't there a straightforward way to handle this > that better fits with the Unix toolbox philosophy? > > E.g. by using a wrapper command to handle the mutual exclusion? > Something like > > with-pidfile /tmp/ld.pid $(LD) ...
Most GNU/Linux (at least) systems provide the flock(1) command which can be used for this purpose. Something like: flock -x $(LOCKFILE) $(LD) ... There is some trickery required to get a good lockfile name, because you want it to be the same for all flock commands within this (potentially recursive!) build but different (one assumes) from lock files in any other builds which are running concurrently. You could try something like: export _MASTERPID ?= $(shell echo $$PPID) MASTERPID := $(_MASTERPID) LOCKFILE := /tmp/linklock.$(MASTERPID) (untested). The downside (?) is that make will think that those commands are actually running and it won't try to schedule other jobs, which cuts down on your parallelism. If make handled the mutexes internally then it could run other jobs that weren't involved in the mutex while waiting. Just a thought... _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make