Re: parallel build of gettext may fail

[Ralf Wildenhues]

I forgot three things in my last reply:

* Bruno Haible wrote on Mon, Oct 30, 2006 at 01:47:59PM CET:
> 
> > 1) Since the inner $(MAKE) is unaware of the work of any outer ones
> > on the `$(BUILT_SOURCES)' targets, there is a race condition for
> > parallel make invocations.  This race easily breaks a build on a system
> > with several CPUs:

> Thanks for the report. I can't reproduce it on a single-CPU machine, but I
> hope this patch fixes it.

Yes, that looks better.  Thank you!

> > Btw, can you reproduce this rewriting of variables in Solaris 'make'?

Let's add another line to the example (at the end), so there is no
mistaken belief that this only happens with macro expansion:

mkdir src build
touch src/a src/b src/c
cd build
tr X '\t' >Makefile <<\EOF
VPATH = ../src
F = a b c
d: $(F)
address@hidden "The first and last are not VPATH-rewritten, because"
address@hidden "after make expands $$(F), the \"make words\" are not completely"
address@hidden "surrounded by white space: '$(F)'"
address@hidden "compare with: $(F), or $(F) or :$(F) ..."
address@hidden "but it really is a scary feature..."
EOF
/usr/ccs/bin/make

> leads to:
> | The first and last are not VPATH-rewritten, because
> | after make expands $(F), the "make words" are not completely
> | surrounded by white space: 'a ../src/b c'
> | compare with: ../src/a ../src/b c, or ../src/a ../src/b ../src/c or :a 
> ../src/b ../src/c ...
  | but it really is ../src/a scary feature...

So that means this rewriting is pretty dangerous when one of your source
tree prerequisites is named `test', `if', `else', or similar...

Last but not least, thanks for making a new release!

Cheers,
Ralf