Re: glitch in bfd/doc

[Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>]

* Rainer Emrich wrote on Wed, Aug 26, 2009 at 09:35:42PM CEST:
> using make -j 4 for example leads to failure in bdf/doc at least for the mingw32
> targets, chew is build 4 times in parallel and the move to chew.exe fails:

Thanks for the report.  bfd/doc/Makefile.am avoids full dependencies on
purpose:

  $(MKDOC): $(srcdir)/chew.c
          $(CC_FOR_BUILD) -o chew.$$$$ $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
            $(H_CFLAGS) $(AM_CPPFLAGS) $(srcdir)/chew.c; \
          $(SHELL) $(srcdir)/../../move-if-change chew.$$$$ $(MKDOC)

  [...]
  # We do not depend on chew directly so that we can distribute the info
  # files, and permit people to rebuild them, without requiring the makeinfo
  # program.  If somebody tries to rebuild info, but none of the .texi files
  # have changed, then nothing will be rebuilt.

  aoutx.texi: chew.c $(srcdir)/../aoutx.h $(srcdir)/doc.str
          $(MAKE) $(MKDOC)
          ...

With several rules calling $(MAKE) $(MKDOC), move-if-change needs to be
atomic, and it needs to be possible to overwrite an existing file.  Your
error looks like MinGW's mv has a short time span in which holds the
target file open and thus doesn't provide the latter (open files cannot
be overwritten on w32).

This could probably be worked around with some other hopefully-atomic
operation such as a 'mkdir lock', 'rmdir lock' around the mv, but I'm
not sure whether it would be worth doing it (and trapping for cleanup
of the lock, and teaching users that got lucky with a crash or a ^C\
to remove the lock file).

[...]
> mv: cannot move `chew.4620' to `chew.exe': Permission denied
> mv: cannot move `chew.2684' to `chew.exe': Permission denied
> make[4]: *** [chew.exe] Error 1
> make[4]: Leaving directory
> `/home/rainer/software/build/x86_64-w64-mingw32/gcc-4.5.0/binutils/bfd/doc'

Cheers,
Ralf