Subject: bug#19964: closed (Re: bug#19964: automake fails if files named“install.sh” and “install-sh”are found in the parent directory)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 24 Feb 2025 23:36:03 +0000

Your bug report

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

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
19964: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19964
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#19964: automake fails if files named“install.sh” and“install-sh” are found in the parent directory
From: Karl Berry <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 24 Feb 2025 16:35:16 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: automake fails if files named “install.sh” and “install-sh” are found in the parent directory
From: Florent Le Coz <[email-masked]>
To: [email-masked]
Date: Fri, 27 Feb 2015 20:50:13 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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