Re: also copy install-sh

[Ralf Wildenhues]

Hi Alexandre,

* Alexandre Duret-Lutz wrote on Tue, Dec 21, 2004 at 02:48:35PM CET:
> On Tue, Dec 21, 2004 at 07:27:40AM +0100, Ralf Wildenhues wrote:
> > * Alexandre Duret-Lutz wrote on Mon, Dec 20, 2004 at 11:07:49PM CET:
> > > Would it make sense if libtoolize did not install any of these
> > > scripts when Automake is used?  That way there is always only
> > > one tool installing them in a given setup.
> >
> > Probably.  But let's ask the question the other way round:  What could
> > be broken if libtoolize did not install any of these?
> 
> If Automake is used, nothing I can think of.

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?

> > Next question:  How does libtoolize reliably detect whether Automake is
> > used (I can guess the answer, but am not certain)?
> 
> I don't think you can do this reliably (but I don't think you have too).
> 
> If AM_INIT_AUTOMAKE is used in configure.ac or if ./Makefile.am exists it
> seems reasonable to assume that Automake is used.
> 
> It is possible to create Automake-based packaged where none of the above
> conditions are true, but people doing that probably do not need any help to
> cope with files installed multiple times.

OK.  We can maybe think about this for HEAD and maybe branch-2-0.  I'd
feel happier with Gary also agreeing to what to do -- he worked most
with the bootstrap issues, I think.

> > Another one:  Can we expect forward-compatibility (in the sense that
> > the newest available script will always be the best)?
> 
> You can expecte backward compatibility (i.e. a newer install-sh should
> work where a previous install-sh used to work) on the stable branch,
> and maybe from HEAD (by this I mean that backward compatibility is not
> broken gratiously, but when we need to it occurs on HEAD -- this has
> happenned to install-sh already).
> 
> Forward compatibility is not to be expected at all (an old install-sh
> cannot cope with the any option introduced in a later install-sh).

OK, thanks.  That was what I meant to ask for.

Cheers,
Ralf