Re: AC_PROG_INSTALL does not trigger install-sh availability

[Ralf Wildenhues]

* Eric Blake wrote on Wed, Sep 15, 2010 at 10:17:39PM CEST:
> On 09/15/2010 01:05 PM, Ralf Wildenhues wrote:
> >This long-standing issue is (related to) PR automake/546 in
> >http://sourceware.org/cgi-bin/gnatsweb.pl?database=automake
> >
> >The issues with letting plain 'automake --add-missing' do the job
> >without AM_INIT_AUTOMAKE present is that we actually have less
> >information available as to what files are needed (but we can guess
> >good enough probably), and that we lose a bit of typo error detection.
> >
> >So my latest thinking on this was to maybe add an --no-am switch to
> 
> Just so I'm clear, your suggesting 'automake --no-am', and not
> 'autoreconf --no-am', right?

Right.  autoreconf is already smart enough to find out whether automake
is used.  (Well, if you consider grepping configure.ac "smart enough",
that is.)

> >explicitly allow copying without requiring AM_INIT_AUTOMAKE.
> >autoreconf could then use that.  WDYT?  Overkill?
> 
> Well, autoreconf could indeed be taught to use that, but it would
> have to first probe for a new enough automake, and that could take
> some time.

Sure.  But the bug's been there, what, more than a decade now,
who cares about another month or so?  (Is this hinting at the
low rate of Automake releases?)

> Also, it's always bugged me that the check for install-sh is a
> configure-time test rather than an m4-time test, meaning that it
> doesn't fail until 'make distcheck'.

It used to be possible to specify the config aux dir at configure time.
There is still code in the src (binutils+gdb+...) tree which assumes
this (in the "..." part of it).  Requiring this fixed at m4 time was a
step back (regression if you like) for these setups.  Similar for
determining other things at m4 time: users often lose freedom to decide
things late that way.

> Maybe it would be nice after
> all to teach autoconf how to check at m4-time, and even supply the
> file automatically given the right command-line argument, without
> having to rely on automake.

At which point we'll have up to possibly four candidates of tools to
provide it: autoconf, automake, libtoolize, gnulib-tool.  Not exactly
orthogonal semantics.

> At any rate, I don't think anything is
> going to change on this front in time for releasing 2.68.

Agreed.

Cheers,
Ralf