Re: libcpp's aclocal.m4 regeneration question. Also is it time fora toplevel "m4" directory?

[neroden at fastmail dot fm (Nathanael Nerode)]

>Probably.  There are some .m4 files in config/ but some contain many 
>macros each.  In addition, they are rather inconsistent about macro naming 
>conventions, using
>
>AC_
>CYG_AC_
>GCC_
>ACX_
>NCN_
>ZW_
>AM_
>
>Except for those copied from other GNU packages or overriding standard 
>autoconf/automake macros, a standard naming convention such as GCC_AC_ 
>should be used.  And some macros should perhaps be contributed back to GNU 
>autoconf.

Personally, I suggest the use of:
* ACX_ for macros which are intended to be part of Autoconf but aren't yet
* AC_ for macros which override standard autoconf macros
* (whatever)_ for macros which are lifted from other packages
* GCC_ for macros specific to GCC (not used in src)
* There shouldn't be any other categories :-), but I have no suggestions if
  there are

>And some are probably obsolete with autoconf 2.59.  This is all 
>good for incremental cleanup a macro at a time, but some bits may be 
>easier once src too is converted to autoconf 2.59.

Yes; converting src to autoconf 2.59 is a Good Thing.  I'm working on it
when I have some free time.

Step One, for anyone who cares, is replacing all direct uses of
{build, host, target}_alias with {build, host, target}_noncanonical in
each subdirectory.  This should be done before 2.59 conversion since the
ACX_*_NONCANONICAL macros are 2.13-safe and 2.59-safe.

-- 
This space intentionally left blank.