Re: also copy install-sh

[Ralf Wildenhues]

[ old thread about libtoolize copying install-sh ]

* Gary V. Vaughan wrote on Fri, Dec 24, 2004 at 10:44:38AM CET:
> Bob Friesenhahn wrote:
> >On Wed, 22 Dec 2004, Ralf Wildenhues wrote:
> >>
> >>Might be an option.  At least for branch-1-5, however, I'd rather
> >>just back out my patch and go back to what people know.  The less
> >>surprises, the better.
> >>
> >>We could also just mention that AC_PROG_LIBTOOL resp. LT_INIT uses
> >>AC_PROG_INSTALL, and thus its requirements (which are documented in
> >>Autoconf docs) have to be met, i.e., there has to be a file `install.sh'
> >>or `install-sh'.
> >>
> >>How about that (just a doc update) instead?
> 
> Certainly we shouldn't take the risk of destabilizing branch-2-0 with
> a code change like this.  If you want to test out the possible solutions
> on HEAD, then that is perfectly fine... in fact, I think it might be
> interesting to have a more complete solution to play with on HEAD.
> 
> The only real problem I see with continuing to assume automake will
> handle install-sh issues, is that we advertise that libtool is perfectly
> useable without automake:  someone who wants downloads and installs
> libtool to use standalone like this can't actually do so without
> manually fudging an install-sh into their tree.  Since the libtool tree
> uses automake it has a perfectly good install-sh, but it isn't copied
> into the install tree so it is lost if the libtool build tree is wiped.
> So the user might end up copying across a random version from another
> package, or having to download automake anyway just to get that file.
> 
> >Sounds good to me.  Maybe libtoolize should warn if install-sh is not 
> >yet present (assuming it knows where it should be).
> 
> It seems unobtrusive to copy libtool's install-sh into $datadir, and
> have libtoolize suggest using $datadir/install-sh if none is present,
> along with a caveat that automake will instead install the definitive
> install-sh later in the bootstrap...
> 
> HEAD can go further and actually perform the copy if automake doesn't
> seem to be in use.

How about these two patches, first against branch-1-5, second against
branch-2-0?  (HEAD will follow later and be solved differently, as
discussed above).

I acknowledge that a rewrite of the different methods to integrate (or
not) Libtool into users' packages is still pending, but I do not have
time for that now (patches welcome).

Regards,
Ralf

branch-1-5:

        * libtoolize.in: Back out copying `install-sh' by libtoolize.
        * doc/libtool.texi (Distributing): Mention that we distribute
        `install-sh', but that non-Automake users will have to copy
        it by themselves.

Index: libtoolize.in
===================================================================
RCS file: /cvsroot/libtool/libtool/Attic/libtoolize.in,v
retrieving revision 1.21.2.2
diff -u -r1.21.2.2 libtoolize.in
--- libtoolize.in       20 Dec 2004 13:10:22 -0000      1.21.2.2
+++ libtoolize.in       13 Jan 2005 10:14:53 -0000
@@ -158,7 +158,7 @@
   echo "$progname: cannot list files in \`$pkgdatadir'" 1>&2
   exit 1
 fi
-files='config.guess config.sub install-sh ltmain.sh'
+files='config.guess config.sub ltmain.sh'
 
 auxdir=.
 auxdirline=`grep '^AC_CONFIG_AUX_DIR' $configure_ac 2>/dev/null`
Index: doc/libtool.texi
===================================================================
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.134.2.7
diff -u -r1.134.2.7 libtool.texi
--- doc/libtool.texi    20 Dec 2004 13:10:25 -0000      1.134.2.7
+++ doc/libtool.texi    13 Jan 2005 10:14:54 -0000
@@ -1852,7 +1852,10 @@
 your package.  @xref{Configuring}.
 
 You should use the @code{libtoolize} program, rather than manually
-copying these files into your package.
+copying these files into your package.  Note however, that @file{install-sh}
+is not copied by @code{libtoolize}; if you use Automake, it will take care
+of that, otherwise you may obtain a copy from the package data directory
+of the installed Libtool.  This may change in a future Libtool version.
 
 @menu
 * Invoking libtoolize::         @code{libtoolize} command line options.

--- cut here ---

branch-2-0:
        * libtoolize.m4sh: Back out copying `install-sh' by libtoolize.
        * doc/libtool.texi (Distributing): Mention that we distribute
        `install-sh', but that non-Automake users will have to copy
        it by themselves.

Index: libtoolize.m4sh
===================================================================
RCS file: /cvsroot/libtool/libtool/libtoolize.m4sh,v
retrieving revision 1.1.2.6
diff -u -r1.1.2.6 libtoolize.m4sh
--- libtoolize.m4sh     28 Dec 2004 13:50:56 -0000      1.1.2.6
+++ libtoolize.m4sh     13 Jan 2005 10:24:25 -0000
@@ -627,8 +627,6 @@
     func_config_update "$pkgdatadir/config.guess" "$auxdir/config.guess"
     test -f "$pkgdatadir/config.sub" \
       && func_config_update "$pkgdatadir/config.sub" "$auxdir/config.sub"
-    test -f "$pkgdatadir/install-sh" \
-      && func_config_update "$pkgdatadir/install-sh" "$auxdir/install-sh"
   fi
   func_ltmain_update "$pkgdatadir/ltmain.sh" "$auxdir/ltmain.sh"
 
Index: doc/libtool.texi
===================================================================
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.172.2.17
diff -u -r1.172.2.17 libtool.texi
--- doc/libtool.texi    12 Jan 2005 16:36:33 -0000      1.172.2.17
+++ doc/libtool.texi    13 Jan 2005 10:24:25 -0000
@@ -2140,7 +2140,10 @@
 your package.  @xref{Configuring}.
 
 You should use the @command{libtoolize} program, rather than manually
-copying these files into your package.
+copying these files into your package.  Note however, that @file{install-sh}
+is not copied by @code{libtoolize}; if you use Automake, it will take care
+of that, otherwise you may obtain a copy from the package data directory
+of the installed Libtool.  This may change in a future Libtool version.
 
 @menu
 * Invoking libtoolize::         @code{libtoolize} command line options.