Simon Josefsson <[EMAIL PROTECTED]> wrote:
> "James Youngman" <[EMAIL PROTECTED]> 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:
>
> [EMAIL PROTECTED]:~/x/gllib$ grep MKDIR Makefile*
> Makefile: $(MKDIR_P) sys
> Makefile.am: $(MKDIR_P) sys
> Makefile.in: $(MKDIR_P) sys
> [EMAIL PROTECTED]:~/x/gllib$
>
> I'm not sure what tools is responsible for adding:
>
> [EMAIL PROTECTED]@
>
> 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.
