ac-archive: obsolete detection and AX_ prefix

[Guido Draheim]

with the ongoing expansion of ac-archive, it started to problematic
to keep the macros sorted out. There has been a discussion a while
back whether it might make sense to reserve a macro-prefix for
those registered in the ac-archive - the usage of AX_ sounds best.

This AX_ prefix is now detected by the `acinclude` distributed in
the tarball of the sfnet branch, and it will warn about any macro
call within a configure.ac that has an AX_ prefix but that could not
be found while creating acinclude.m4 - this has worked quite well
for a while and I want to start now asking maintainers of extra
ac-macros to pick up this AX_ prefix in the future.

A deeper reasoning comes from the fact that the ac-archive has
now a series of macros available that follow a certain scheme,
look for the great work of Luc Maisonobe for the C++-Support
section - it has now ac-macros for all relevant differences in
c++ compilers at hand. Perhaps some of these will diffuse later
into the autoconf base package and in which case these macros
might come to exist multiple times - both in an acinclude.m4 and
in the systems autoconf installation.

Even now, some people have started to rename their macros from
using the AC_-prefix to something different. That makes it
perhaps not easy for maintainers of large software sites to
keep up with updates of extra ac-macros - unlike the autoconf
base package, they are not extra tested and it is therefore quite
likely be see them changed for finding little bugs around, or
perhaps even replaced with another one that has a better call
synopsis and different defaults for empty arguments.

Where the gnuorg branch simply deletes the old files, I have come
to the conclusion to keep the old ac-macros around under their
old name for a while (a year or so) and instead put a marker
"obsoleted by ..." into the header of these .m4 files. That makes
it easy for large-site maintainers to find renamed/obsoleted
macros - they can simply `grep` them for "obsoleted". Additionaly,
the `acinclude` tool from the sfnet ac-archive will utter now
non-fatal warning messages for every of these as well.

hints? comments? objections? ;-)

-- cheers, guido                         http://ac-archive.sf.net