[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 10 failures in recent automake checkout testsuite under Solaris 9

From: Ralf Wildenhues
Subject: Re: 10 failures in recent automake checkout testsuite under Solaris 9
Date: Mon, 12 Jun 2006 20:06:01 +0200
User-agent: Mutt/1.5.11+cvs20060403

* Ralf Wildenhues wrote on Sat, Jun 10, 2006 at 04:40:57PM CEST:
> There is still an Automake problem with this patch, exposed by a
> nobase.test failure: install-sh needs executable permissions set so that
> it works with AC_PROG_MKDIR_P (they can be unset if install-sh comes
> into play by means of a patch or so).  Autoconf OTOH can't easily set
> $MKDIR_P to '$(SHELL) path/to/install-sh' because that would break for
> non Makefiles.  I presume it could set "$SHELL path/to/install-sh",
> expanding $SHELL at config.status time.  I don't know whether anything
> could be broken by that though.

One other possibility would be to set MKDIR_P to "\${SHELL} $ac_install_sh"
like below.  (Prepending $INSTALL, or $ac_install_sh, with \${SHELL} is
IMVHO much too risky at this point, however.)
This would require a decently-set $SHELL though.

Furthermore, I think it doesn't hurt to mention the don't-change-
directories limitation more prominently.

The patch below does both of this.  It will cause slightly ugly
configure output:
| checking for a thread-safe mkdir -p... ${SHELL} ../install-sh -c -d

and all in all I'm really not sure whether we shouldn't just convince
users to fix the file permissions of install-sh instead.

What do you think?

(Again, there is the possibility to just expand $SHELL at configure
time; I'm simply not sure whether the value should be overridable at
make time.)


        * doc/autoconf.texi (Particular Programs): Mention that $MKDIR_P
        may not be used from a changed directory.  Mention that ${SHELL}
        may need to be set for its expansion.
        * lib/autoconf/programs.m4 (AC_PROG_MKDIR_P): Use `\${SHELL}' to
        call install-sh.

Index: doc/autoconf.texi
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1042
diff -u -r1.1042 autoconf.texi
--- doc/autoconf.texi   8 Jun 2006 17:25:10 -0000       1.1042
+++ doc/autoconf.texi   12 Jun 2006 16:54:31 -0000
@@ -3533,14 +3533,18 @@
 This macro uses the @samp{mkdir -p} command if possible.  Otherwise, it
 falls back on invoking @command{install-sh} with the @option{-d} option,
-so your package should
-contain @file{install-sh} as described under @code{AC_PROG_INSTALL}.
+so your package should contain @file{install-sh} as described under
address@hidden, and should not invoke @code{MKDIR_P} from a
+changed directory.
 An @file{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 @file{install-sh}.  In particular, be careful about
 using @samp{autoreconf -if} if your Automake predates Automake 1.10.
+Furthermore, @code{MKDIR_P} may expand @code{SHELL}, so you should ensure
+its definition in a manually written config file, e.g., by adding
 This macro is related to the @code{AS_MKDIR_P} macro (@pxref{Programming
 in M4sh}), but it sets an output variable intended for use in other
Index: lib/autoconf/programs.m4
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/programs.m4,v
retrieving revision 1.60
diff -u -r1.60 programs.m4
--- lib/autoconf/programs.m4    31 May 2006 20:52:38 -0000      1.60
+++ lib/autoconf/programs.m4    12 Jun 2006 16:54:31 -0000
@@ -679,7 +679,7 @@
     # break other packages using the cache if that directory is
     # removed, or if the value is a relative name.
     test -d ./--version && rmdir ./--version
-    MKDIR_P="$ac_install_sh -d"
+    MKDIR_P="\${SHELL} $ac_install_sh -d"
 dnl Do special magic for MKDIR_P instead of AC_SUBST, to get

reply via email to

[Prev in Thread] Current Thread [Next in Thread]