Hello Peter, * Peter O'Gorman wrote on Wed, Sep 06, 2006 at 01:08:53AM CEST: > >>On Sun, Sep 03, 2006 at 09:33:20AM +0200, Ralf Wildenhues wrote: > >>>I say we drop the test and require that install-sh be executable. > >>>After all, this is so much easier to do.
> On a regular basis, I patch packages to use the autotools build > system that did not originally do so. Our build system unpacks the > original tarball and applies patches with patch. This means that > scripts get created without execute bits, so the build fails. The > idea of the test that Alexandre installed was to ensure that automake > would be able to continue to run without executable bits being set, > not so that the test could be removed when someone broke automake so > that it no longer works without being executable. Ok, let me formulate this differently: Autoconf and Automake have _never_ really supported a non-executable `install-sh' script in the source tree. The test exposed merely one of several different usage cases, many of which would have always failed. When this change was first installed, I didn't like it, but also I did not see all the failure cases. Now that I see them (and that is not only the move to use AC_PROG_MKDIR_P), I think it is far too much hassle and the risk of breaking users' package setups may be too high, IMVHO. For example, the $(INSTALL), $(INSTALL_DATA), and $(INSTALL_PROGRAM) are documented interfaces of Autoconf, and have never been safe for this. The new Autoconf interface $(MKDIR_P) is documented to be used without prefixing $(SHELL). Maybe there is a solution to all cases. But until then, I don't think it's a good idea to advertise half-solutions, and employ half-tests. And yes, that is very much IMHO. Cheers, Ralf
