[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_PROG_INSTALL does not trigger install-sh availability
From: |
Ralf Wildenhues |
Subject: |
Re: AC_PROG_INSTALL does not trigger install-sh availability |
Date: |
Wed, 15 Sep 2010 22:33:49 +0200 |
User-agent: |
Mutt/1.5.20 (2010-08-04) |
* 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