There was a time that the autoconf project was invented to help people make their projects more portable and it was a time that the basic autoconf project provided all the means to do it, and the automake project invented the "aclocal" tool to augment on top of it with macro series provided by other packages which they were installing in the /usr/share/aclocal subdirectory. There you will find macro-files like "libtool.m4" which hold the macros to properly "configure" the functionality of these tools in the case that a developer wants to use them in a project. And the "aclocal" tool will detect the macros in the "configure.in" script copying the needed macros a file called "aclocal.m4" which the "autoconf" tool will see automatically and bind in to its resources otherwise coming from /usr/share/autoconf.

However, the macros in package-specific "share/aclocal" and the base functionality in "share/autoconf" do not adress a specific area: the use of macros in multiple projects where these macros are neither general w.r.t. to portability and neither project-centric w.r.t. to just one project. These are often some feature tests developed in one project and that was found useful enough to be reused in other projects - and it is the natural way to give it a name and reference the functionality by its name - et voila, this is what the term "macro" says, to pack a series of commands under a name, possibly with some arguments that to carry package-specific variables into the heart of the memorized feature test.

It happens to be very easy to develop such a macro, (1) just cut out your shell script that you came to test a feature, and put it into its own file, e.g. "ac_mytest.m4". (2) Then put up the trailer and footer that you can see in the "contribution" example or in any of the other ac-archive scripts - i.e. add a comment-block (using the "dnl"-m4-comment instead of the "#"-sh-comment) and the AC_DEFUN([AC_MYTEST],[......]) declaration to give it the name "AC_MYTEST". And (3) do not forget to look for the "["s and "]"s in the macro body since these are the autoconf-quotes - just double them into "[["s and "]]"s which "autoconf" will shrink back to simple square when it expands your "configure.ac" to the "configure" script. Well, that's all what is needed to create an ac-macro.

The next step is not related to creation of an ac-macro but how make these to be reused in multiple projects. Just copying the bew file "ac_mytest.m4" to that project directory is not enough since neither "aclocal" nor "autoconf" will see it automatically. The way to manage these has a bit of history to watch out for. (a) "autoconf" tool will use all the macros in "share/autoconf/" directory plus the macros in "aclocal.m4" in the project directory. (b) "aclocal" will use all the macros in "share/aclocal" plus the macros in "acinclude.m4" in the project directory.

To augment on these tools, the traditional way is (A) create a subdirectory "m4/" in your project directory, copy the ac-macros thereunder and make sure to call "aclocal -I m4" to have these macros copied into "aclocal.m4" - to ensure this, watch out for "automake" which will create a rule in its "Makefile.in" to call "aclocal" automatically. There is an option called $(ACLOCAL_AMFLAGS) you can use to add the requried subdir for it. (B) just copy the two macros you need into the project directory, and "cat" the two macros together into the "acinclude.m4" file, i.e. "cat mytest1.m4 mytest2.m4 >acinclude.m4" - downside: you want to do that only for one or two macros, not a dozen of them.

Well, both of these ways have a drawback - when you update your cross-project ac-macro, how do you distribute the changes to other project directories? Originally, the "aclocal" command could distribute the changes, and that is what Guido Draheim started to do - to create a distribution archive including rpm file that will install the extra macros into "share/aclocal" so that all projects will instantly find the updated ac-macro. This was convenient for his two dozen macros, and the project was called "aclocals" to give the impression to extend the "aclocals" macros being installed. However, later he discovered the Autoconf Macro Archive invented by Peter Simons, and instantly started to reuse some of the macros stored there - which of course results in two competeing strains of update paths with both packaging tarballs to carry around macros. Well, in the opensource world there is never something wrong with solving the problem of overlap between two projects - merge them!

I do not want to delve into the specifics why the merge did not succeed instantly with the sfnet branch showing the benefit that the "aclocals" packaging system can provide to the ac-archive - the gnu-hosted series was an attempt to merge the site with Peter's project homepage but he did never publish the build toolchain at savannah. Given the tight-fisted control there the SF-branch did continue to exist showing at the time an alternative html generator output. Peter Simons did later quit the ac-archive-maintainers moving back to his personal autoconf-archive at cryp.to. It is unkown whether a merger can complete somewhen in the future. As all his macro tool sources are hidden it seems improbable.

The flame war following the GNU merger announcement might enlighten about the relationship. More did follow over the years being mostly present on the autoconf mailing list.