* 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
