Automake shooting in its foot

[akim]

I tracked down the CXX definition in the fileutils' Makefile.ins, and
it's damned stupid...

Automake comes with its own set of macros, for instance to set up
AM_DEPENDENCIES.  Whoever uses automake will include these macros in
aclocal.m4.  Then automake, when scanning aclocal.m4 will find
AC_PROG_CC, AC_PROG_CXX etc. in there, and will conclude that the
package uses CC, CXX etc. and will define those vars.

Seeing this autoscan will ask for an actual use of AC_PROG_CC, since
it knows for real what is used and what is not: it uses autoconf's
--trace...

Actually it is just the same when running autoscan on Automake:
because of aclocal.m4 you'll have:

~/src/automake-1.4c % ../ace/autoscan -A ../ace                       0:35 remo
warning: missing AC_PROG_CC wanted by: Makefile.in:64 m4/Makefile.in:64 
tests/Makefile.in:64
warning: missing AC_PROG_CPP wanted by: Makefile.in:65 m4/Makefile.in:65 
tests/Makefile.in:65
warning: missing AC_PROG_CXX wanted by: Makefile.in:66 m4/Makefile.in:66 
tests/Makefile.in:66

So, IMHO, we have just no issue until we release an autoconf --trace
aware automake.  And frankly, I can't wait :) Automake will be much
shorter (less hard coded knowledge on Autoconf), more robust (less
hard coded knowledge on Autoconf), and more extendible (less hard
coded knowledge on Autoconf).

It'd be great if the Autotools could decide for real that once their
2.50, 1.5 and 1.4 version release, we should make a stop, releasing
about the same packages with very few changes, but requiring 2.50 or
2.51.

Automake will require autoconf --trace and drop dead compatibility
with older Autoconves, and Libtool too, taking advantage of a decided
and clean means to hook its stuff to Autoconf's AC_PROG_CC
etc. (likewise for Automake's dependency tracking macros).

AC_PROG_CC and the like are overloaded to death, and I don't want to
be there when they blow out.