GNU bug report logs - #19964
automake fails if files named “install.sh” and “install-sh” are found in the parent directory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19964 in the body.
You can then email your comments to 19964 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Florent Le Coz <louiz <at> louiz.org>
To: bug-automake <at> gnu.org
Subject: automake fails if files named “install.sh” and “install-sh” are found in the parent directory
Date: Fri, 27 Feb 2015 20:50:13 +0100

Software versions:
automake (GNU automake) 1.14.1
aclocal (GNU automake) 1.14.1
autoconf (GNU Autoconf) 2.69
autoreconf (GNU Autoconf) 2.69


Assuming project.tar.gz contains the source code of a project using
the autotools as its build system:

$ tar xf project.tar.gz
$ cd project/
$ touch ../install-sh ../install.sh
$ autoreconf -vif
autoreconf: Entering directory `.'
[…]
BUG.am: error: 'install.sh' is an anachronism; use 'install-sh' instead
[…]
autoreconf: automake failed with exit status: 1

$ rm ../install-sh ../install.sh
$ autoreconf -vif
autoreconf: Entering directory `.'
[…]
autoreconf: Leaving directory `.'
$ echo $?
0

It seems to be related to this code (taken from the last git revision)

      # The default auxiliary directory is the first
      # of ., .., or ../.. that contains install-sh.
      # Assume . if install-sh doesn't exist yet.
      for my $dir (qw (. .. ../..))
        {
          if (-f "$dir/install-sh")
            {
              $config_aux_dir = $dir;
              last;
            }
        }

Which sets $config_aux_dir to "..", but then later we look for
install.sh in that directory

  err_am "'install.sh' is an anachronism; use 'install-sh' instead"
    if -f $config_aux_dir . '/install.sh';

You probably have reasons to look in .. or ../.. (and I would be
quite interested to hear them, actually), but I don’t think it
should fail in the specific case I described above.  I don’t
think it’s safe to assume that the parent directory of a project
is not filled with garbage (mine was full or random files,
including a install.sh and install-sh files, for some reasons).

Plus, it was really, really hard for me to understand which
“install.sh” file this error was talking about, since I could not
find any such file in my working directory or any sub-directory.

Regards

-- 
Florent

Message #8 received at 19964 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Florent Le Coz <louiz <at> louiz.org>
Cc: 19964 <at> debbugs.gnu.org
Subject: Re: bug#19964: automake fails if files named “install.sh” and “install-sh” are found in the parent directory
Date: Fri, 27 Feb 2015 16:02:04 -0500

> Assuming project.tar.gz contains the source code of a project using
> the autotools as its build system:
> 
> $ tar xf project.tar.gz
> $ cd project/
> $ touch ../install-sh ../install.sh
> $ autoreconf -vif
> autoreconf: Entering directory `.'
> […]
> BUG.am: error: 'install.sh' is an anachronism; use 'install-sh' instead
> […]
> autoreconf: automake failed with exit status: 1

Full test case:

  % mkdir foo
  % cat >foo/configure.ac <<'EOF'
AC_INIT([test], [0])
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
  % touch foo/Makefile.am
  % touch install-sh install.sh
  % (cd foo && autoreconf -i)
configure.ac:2: installing '../missing'
BUG.am: error: 'install.sh' is an anachronism; use 'install-sh' instead
autoreconf-2.69: automake failed with exit status: 1

Note how it actually copies the missing script to ".." as well, and NOT
into the package directory.  If we remove just ../install.sh automake
will still copy files into "..", and 'make dist' will fail to include
them in the tarball.

> You probably have reasons to look in .. or ../.. (and I would be
> quite interested to hear them, actually)

I imagine it is for subprojects, so that the scripts are not copied into
every one.  Which unfortunately means changing the automake behaviour
could break this usage...

However, there is a workaround.  If you add AC_CONFIG_AUX_DIR([.]) to
configure.ac, then this will cause Automake to not look in .. or ../..,
and things should work properly.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Message #17 received at 19964-done <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: louiz <at> louiz.org
Cc: 19964 <at> debbugs.gnu.org
Subject: Re: bug#19964: automake fails if files named
 “install.sh” and
 “install-sh” are found in the parent directory
Date: Mon, 24 Feb 2025 16:35:16 -0700

Hi Florent - you sent in a report about automake gratuitously finding
install.sh in a parent directory back in 2015 (!). Sorry.

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19964

    You probably have reasons to look in .. or ../.. (and I would be
    quite interested to hear them, actually), 

According to the autoconf manual (AC_CONFIG_AUX_DIR is an autoconf
directive, not automake):

  For convenience when working with subdirectories with their own
  configure scripts (*note Subdirectories::), if the scripts are not in
  `SRCDIR' it will also look in `SRCDIR/..'  and `SRCDIR/../..'

Personally I find this less than compelling as an argument, but it's
been that way forever and it would cause much too big a compatibility
problem to change it now, IMHO. (Though I am not the autoconf maintainer.)

Anyway, back on your report:

       err_am "'install.sh' is an anachronism; use 'install-sh' instead"
         if -f $config_aux_dir . '/install.sh';

    ... I don't think it should fail in the specific case I described above.

I agree. I changed the error to a warning. The presence of a stray
install.sh file hardly seems fatal.

    hard for me to understand which ``install.sh'' file this error was
    talking about

Yes, that must have been frustrating. I also changed the message to
include the full location of the install.sh that was found.

Thanks for the report, and finding the spot in the code. Closing this
bug now, but feel free to reply/reopen or open a new issue if
desired. --thanks, karl.

-----------------------------------------------------------------------------
automake: warn about install.sh being found, rather than error.

Report from https://bugs.gnu.org/19964.

* bin/automake.in (scan_autoconf_files): give a msg 'obsolete'
rather than err_am. Mention where install.sh was found.
(En passant, fix some doubled words.)
* NEWS: mention this.
diff --git a/NEWS b/NEWS
index d06de78fd..9c1b56851 100644
--- a/NEWS
+++ b/NEWS
@@ -41,10 +41,13 @@ New in 1.x:
   - The compile script is more robust to Windows configurations;
     specifically, avoiding double-path translation on MSYS. (bug#75939)

+  - Only warn about install.sh being found, instead of it being a fatal
+    error. (bug#19964)
+
   - AM_SILENT_RULES once again always ends with a newline. (bug#72267)

diff --git a/bin/automake.in b/bin/automake.in
index 70c512af2..a92b02e06 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -5668,8 +5668,15 @@ sub scan_autoconf_files ()
     {
       require_conf_file ($required_aux_file{$file}->get, FOREIGN, $file)
     }
-  err_am "'install.sh' is an anachronism; use 'install-sh' instead"
-    if -f $config_aux_dir . '/install.sh';
+  
+  my $auxdir_install_dot_sh = "$config_aux_dir/install.sh";
+  # Maybe there is a way to report the line number of the
+  # AC_CONFIG_AUX_DIR call in configure.ac? Don't know.
+  msg 'obsolete', "$configure_ac", "'install.sh' is an anachronism\n"
+                                 . "  (found in $auxdir_install_dot_sh,\n"
+                                 . "   defined by AC_CONFIG_AUX_DIR);\n"
+                                 . "  use 'install-sh' instead"
+    if -f $auxdir_install_dot_sh;

compile finished at Mon Feb 24 15:33:37 2025

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.