If you want to contribute ...

then please don't hesitate a second! Just send the m4 source to one of the maintainers. Currently (October 2006) that is Guido Draheim (guidod:at:gmx'de) and Tom Howard (tom:at:howardfamily'id'au) for the AC-Archive at Sourceforge and Peter Simons (simons:at:cryp'to) for the Autoconf-Archive at CrypTo. (We will try to create a common mailing to replace the old ac-archive-maintainers@gnu.org mailinglist in the near future.) In any case, please read the following section about the contribution format.

Contribution Format

For one thing - I would appreciate if you could split your macros into one-per-mail, rather than sending me your whole aclocal.m4 file, because this makes the inclusion of the submission into the archive much easier for me. It also allows me to review your macro and send you some hints (if you do not want that, please notify me, I just want to be helpful).

Also, I'd like to ask you to adhere to a few formatting rules in your submissions: Every macro should start with a few comment lines, describing what exactly it tests, what results it does produce and how it may be called by potential users. After the comments, the actual m4 code follows.

In the comments, you should use a few directives to mark special contents, that is interpreted by the perl scripts which convert the m4 input to the HTML page the users will see:

@synopsis

This keyword should be followed by a one-line example, showing how to use the autoconf macro, similar to the synopsis line in the usual Unix man files.

@version

This keyword usually contains the string "$Id$" to have the version automatically maintained by CVS here on the server. You should set it manually, though, as the version number in the archive repositories might differ otherwise.

@author

You have written the macro, so please say so and state your name and e-mail address after this keyword, so that users may express their gratitude, report problems or suggest enhancements.

@license

It is strongly advisable to add an explicit license hint - at best "AllPermissive" for free usage (assumed MIT-style) or compatible with the Autoconf Project as "GPLWithACException". Any other free license is okay as well - known licenses might simply be enhanced with a weblink to the full text.

@category

Please pick one of the categories as seen on the left navigation bar at ac-archive.sf.net - usually some programming language support (AM,C,C++,Fortran,Java). If it does not fit just pick Misc as the category. You can also add multiple category tags.

@summary

Purely optional, you can add a one-line description below the @synopsis might be included in overview index pages (where the full documentation does not fit in and the @synopsis is not clarifying enough).

Here is an example, how your submission should look like:
(Press "Convert!" to see the resulting webpage as would be shown here)

Macro names should always be quoted in brackets, otherwise Autoconf will break in case a macro definition is (accidently) included multiple times in a configure.in file, as the macro name would be expanded the second time the definition is parsed. Note that autoconf can warn about symbols starting with AC_ or AM_ when it does exist but has not been found. That is a nice trick, however one should rarely start naming macros with the AC_/AM_ prefix since they might coincide with names of macros from future versions from autoconf/automake and which would shadow your own macro then.

The AX_ prefix is reserved for the usage in the extra archive repositories and it will be ensured that only one macro of the different name exists here. Additionally, the `acinclude` and `acincludedir` tool will recognize macros with this prefix, warns about missing items and be able to populate an acinclude.m4 and/or m4/* subdirectory with extra macros.
The AX prefix is therefore recommended now.