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
