History		0.5.65

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 ac-archive project 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 is pretty much the original site that was present as a subdirectory of Peter's homepage and which is now a subdirectory at www.gnu.org. Let's hope that the final pieces can be solved later and the sfnet branch will degenerate to a place for pure experimentation ... and rpm series which I doubt will be shipped on the gnu.org servers sometime soon.

Update: it seems there is some new work going on at the gnu.org website, there had been a long flame war starting from the announcement that has some more information about the current relationship of the two ac-archives.