[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parallel build dependency locking
From: |
Boris Kolpackov |
Subject: |
Re: Parallel build dependency locking |
Date: |
Wed, 8 Jun 2005 16:15:00 +0000 (UTC) |
User-agent: |
nn/6.6.5+RFC1522 |
First off, there are no threads; GNU make issues (certain) commands in
parallel when run with -j flag.
Christopher Sean Morrison <address@hidden> writes:
> fast: fast-local $(FAST_OBJECTS) fast-recursive all
>
> fast-recursive:
> @list='$(SUBDIRS)'; for subdir in $$list; do \
> test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS)
> fast);
> \
> done
Perhaps you are building the same object file from two concurrent make
invocations. One is current and the other is the result of the
fast-recursive rule?
> Compared to wavelet.c, vers.c is very trivial so I can see how a thread
> working on vers.lo would finish before the wavelet.lo target's thread
> gets a chance to even start writing.
> That would only make sense,
> though, if the OBJECTS are not being properly locked by make on a
> parallel build
GNU make doesn't do any locking, AFAICT.
> -- and it doesn't seem to explain why the libbn.la
> target with the same target dependancies doesn't exhibit the same
> problem.
Perhaps it's because fast-recursive rule is not built?
hth,
-boris
- Parallel build dependency locking, Christopher Sean Morrison, 2005/06/08
- Re: Parallel build dependency locking,
Boris Kolpackov <=
- Re: Parallel build dependency locking, Christopher Sean Morrison, 2005/06/08
- Re: Parallel build dependency locking, Boris Kolpackov, 2005/06/09
- Re: Parallel build dependency locking, Christopher Sean Morrison, 2005/06/09
- Re: Parallel build dependency locking, John Graham-Cumming, 2005/06/09
- Re: Parallel build dependency locking, Christopher Sean Morrison, 2005/06/09
- Re: Parallel build dependency locking, John Graham-Cumming, 2005/06/09
- Re: Parallel build dependency locking, Paul D. Smith, 2005/06/10