Re: Use "$(MKDIR_P) sys", not race-prone "test -d sys || mkdir sys".

[Jim Meyering]

Simon Josefsson <address@hidden> wrote:
> "James Youngman" <address@hidden> writes:
>
>> However, I think the problem is that on this system, the Makefile.in
>> file is not actually using @MKDIR_P@ :-
>
> Yes, I still get the same problem.  I have tried Bruno's patch, but it
> makes no difference.  The problem seems indeed to be that Makefile.in
> doesn't use @MKDIR_P@ at all:
>
> address@hidden:~/x/gllib$ grep MKDIR Makefile*
> Makefile:       $(MKDIR_P) sys
> Makefile.am:    $(MKDIR_P) sys
> Makefile.in:    $(MKDIR_P) sys
> address@hidden:~/x/gllib$
>
> I'm not sure what tools is responsible for adding:
>
> address@hidden@
>
> line to Makefile.in, which is likely where the problem is.

Well, perhaps autoconf is relying too much on automake-1.10
when it describes AC_PROG_MKDIR_P as setting the output
variable, MKDIR_P.  autoconf-2.61a fails to do that when used
with automake-1.9.6.  However, it does set mkdir_p, so if
my changes to use $(MKDIR_P) had instead used the undocumented
(in autoconf) $(mkdir_p), this would not be a problem for Simon.
As the comments say, we see that mkdir_p is defined more often
than MKDIR_P.

To reproduce, put automake-1.9.6 early in your path and do this:

  $ /path/to/gnulib/gnulib-tool --dir x --with-tests --create-testdir gettime
  ...
  config.status: creating Makefile
  config.status: creating config.h
  config.status: executing depfiles commands
  sys
  make: sys: Command not found
  make: *** [sys/time.h] Error 127
  [Exit 1]

This automake documentation is ironic, considering that the deprecated
*mkdir_p* turns out to be the more portable definition:

     Nowadays Autoconf provides a similar functionality with
     `AC_PROG_MKDIR_P' (*note Particular Program Checks:
     (autoconf)Particular Programs.), however this defines the output
     variable `MKDIR_P' instead.  Therefore `AM_PROG_MKDIR_P' has been
     rewritten as a thin wrapper around `AC_PROG_MKDIR_P' to define
     `mkdir_p' to the same value as `MKDIR_P' for backward
     compatibility.

     If you are using Automake, there is normally no reason to call this
     macro, because `AM_INIT_AUTOMAKE' already does so.  However, make
     sure that the custom rules in your `Makefile's use `$(MKDIR_P)'
     and not `$(mkdir_p)'.  Even if both variables still work, the
     latter should be considered obsolete.


BTW, regarding packages that don't yet use autoconf-2.60 or automake-1.10,
they should be warned that there is now a race (creating lib/sys/)
that can cause parallel build failure [from autoconf.info]:

     An `install-sh' file that predates Autoconf
     2.60 or Automake 1.10 is vulnerable to race conditions, so if you
     want to support parallel installs from different packages into the
     same directory you need to make sure you have an up-to-date
     `install-sh'.  In particular, be careful about using `autoreconf
     -if' if your Automake predates Automake 1.10.