Re: parallel build of gettext may fail

[Bruno Haible]

Hello Ralf,

> 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:
> ...
> mv -f alloca.h-t alloca.h
> make[1]: Entering directory 
> `/tmp/gettext/build-0.16/gettext-tools/libgettextpo'
> make[1]: `config.h' is up to date.
> make[1]: `gettext-po.h' is up to date.
> { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
>           cat ../../../gettext-0.16/gettext-tools/libgettextpo/alloca_.h; \
>         } > alloca.h-t
> rm -f configmake.h-t configmake.h
> mv -f alloca.h-t alloca.h
> { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
>           echo '#define PREFIX "/usr/local"'; \
> ...
> mv: cannot stat `alloca.h-t': No such file or directory
> make[1]: *** [alloca.h] Error 1

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

*** gettext-tools/libgettextpo/Makefile.am.bak  2006-10-26 04:53:00.000000000 
+0200
--- gettext-tools/libgettextpo/Makefile.am      2006-10-28 19:51:24.000000000 
+0200
***************
*** 108,115 ****
  
  # Hide symbols that are defined by libgettextpo_la_AUXSOURCES or libgnu.la
  # from the global namespace, by prefixing them with "libgettextpo_".
! BUILT_SOURCES += config.h
! config.h:
        { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          : "Avoid double inclusion, to avoid a warning about redefinition of 
DLL_VARIABLE."; \
          echo '#ifndef GTPO_CONFIG_H'; \
--- 108,115 ----
  
  # Hide symbols that are defined by libgettextpo_la_AUXSOURCES or libgnu.la
  # from the global namespace, by prefixing them with "libgettextpo_".
! all check install: config.h
! config.h: $(BUILT_SOURCES)
        { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          : "Avoid double inclusion, to avoid a warning about redefinition of 
DLL_VARIABLE."; \
          echo '#ifndef GTPO_CONFIG_H'; \
***************
*** 125,131 ****
          echo; \
          echo '#endif /* GTPO_CONFIG_H */'; \
        } > config.h && \
-       { $(MAKE) $(BUILT_SOURCES) || { rm -f config.h; exit 1; }; } && \
        if test -n "$(HAVE_GLOBAL_SYMBOL_PIPE)"; then \
          { \
            for f in $(libgettextpo_la_AUXSOURCES) $(libgnu_la_SOURCES) 
$(libgnu_la_LIBADD); do \
--- 125,130 ----


> 2) Solaris make with its dreaded VPATH rewriting "feature" will, in this
> loop:
> 
> for f in $(libgettextpo_la_AUXSOURCES) $(libgnu_la_SOURCES) 
> $(libgnu_la_LIBADD); do \
>               case $$f in \
>                 *.c | *.$(OBJEXT) | *.lo ) \
>                   sf=`echo "$$f" | sed -e 's,\\.[^.]*$$,,'`.c; \
>                   of=`echo "$$f" | sed -e 's,^.*/,,' -e 
> 's,\\.[^.]*$$,,'`.$(OBJEXT); \
>                   $(COMPILE) -c $(srcdir)/$$sf || { rm -f config.h; exit 1; 
> }; \
> 
> rewrite all f that point to files from the source tree to contain a
> $(srcdir) prefix.  Since you do not strip it, the compile command will
> pass a doubled $(srcdir) prefix.

Solaris 'make' is not supported for VPATH builds. See the INSTALL file:

     To do this, you must use a version of `make' that
     supports the `VPATH' variable, such as GNU `make'.

Btw, can you reproduce this rewriting of variables in Solaris 'make'? I
saw it once around 2001 or earlier, but when I wanted to reproduce the problem,
in order to have an argument for asking the automake people to drop support
for Solaris 'make', I couldn't.

> Automake itself works around this (in non-inference rules) like this:
>    ... -c `test -f '$(SOURCE)' || echo '$(srcdir)/'`$(SOURCE)

I thought this idiom was in order to cope with files that are sometimes in
the build dir, sometimes in the source dir (such as the elements of
$(BUILT_SOURCES).)

Bruno