There are a lot of helper macros within the autoconf-2.5x base m4 files that you can reuse. This is largely recommended - this file just names a few of them which are extra helpful when writing autoconf extension macros. Note also all the other definitions that you can find in share/autoconf/autoconf/m4sugar/m4sh.m4

AS_VAR_PUSHDEF([VAR],[ax_cv_name_$1]) / AS_VAR_POPDEF([VAR])

Macro developers get sometimes into conflict: use a short variable name and perhaps have name clashes, or use a long name for a shell variable and make the macro almost unmaintainable. The PUSHDEF/POPDEF is helpful here, it does even transliterate the right-hand argument to a good name (if it contains non-alnum characters). Between PUSHDEF and the closing POPDEF you can then just use VAR and it will be replaced with the long name.

  AC_DEFUN([AX_CHECK_MACRO],[dnl
  AS_VAR_PUSHDEF([VAR],[ax_cv_check_macro_$1])
  AC_CACHE_CHECK([for $1 available],
  VAR,[VAR="no"
    AC_TRY_COMPILE
  ])
  AS_VAR_POPDEF([VAR])dnl
  ])

If you call AX_CHECK_MACRO(this-test) then `configure` will create a cache-variable "ax_cv_check_macro_this_test" as a result. (Btw, note that (a) cache variables needs to have "_cv_" in the name to be saved and (b) the ax-prefix helps to not clash with names from core autoconf.)

AC_RUN_LOG([: whatever])

Sometimes you do not want to harrass the final user of a configured project but still memorize some debugging values somewhere like the config.log - the autoconf base does not export an extra macro to write to config.log without showing on the user screen (which would be done with AC_ECHO/AC_MSG_NOTICE) etc). However you can use a trick using AC_RUN_LOG - just put a colon ":" up front. This is a builtin shell command being a "noop", i.e. parse the rest of the line as if they were arguments for a command, and execute the command ":" which does simply do nothing at all. As a result ": whatever" will get put into config.log but nothing else is done, not even a single line will be seen on stdout.

proper quoting with [] and [VAR] and [[whatever]]

The m4 macro processor will expand everything known as NAME - unlike shell scripts it is not required to have a "$" in front or some "()" after it. That's why one should use [..] wherever you want to be sure that it does not get expanded - e.g. AC_DEFUN(HELLO) might break havoc if someone else has already defined a HELLO macro as it would be expanded before AC_DEFUN gets to see the result(!).
 
Furthmore, if you use arguments on a macro then the arguments are broken at each ","-comma - that is another problem if the text does contain some "," which is not unusual in C sources and even some shell sources. Therefore, []-quote non-macro text as often as possible. And the non-macro text contains some [ ] itself then (e.g. for "sed" char-ranges) then remember to use [[..]] instead which helps to preserve a []-pair (or all pairs if it used on the whole text block). Note that the autoconf manual has a lot more to say about m4 quoting.

breaking lines with "dnl" and dnl'ing m4-managment macros.

Shell text is generally sensitive to line-breaks - it does end a command. One might try to continue the command line using \ at the end of the line but you do not need to do that - use can use "dnl" at the end of the line. This is the "m4" line-comment token as that the rest of the line will be ignored by m4/autoconf - however it is different from "#"-shell-comment: the trailing newline will not be output either. Therefore,

 echo the $my_val value happens to dnl
     be different than $other_val
  

will end up in the `configure` script as

 echo the $my_val value happens to      be different than $other_val
  

This scheme is also recommended for m4-management lines to prevent them from issuing unecessary empty lines - which are sometimes even significant to the bourne-shell or may confuse others. Therefore, have a look above at the AS_VAR_PUSHDEF example where we did put about a lot of "dnl" to escape the line-end from being put into the final `configure` script.

$srcdir and AS_MKDIR_P and AS_BASENAME

Quite some macro developers are not aware that `automake` allows to emulate the VPATH feature of many `make` engines. This allows to build the .o object files in a different directory than the .c source file with a Makefile that looks otherwise as if it is supposed to be in the source directory. This can be done simple - just create a directory somewhere and run the `configure` script in there, e.g.

  mkdir my-build-dir
  cd my-build-dir
  sh ../configure

As a macro developer however you should be aware to use $srcdir whenever you refer to a file from the source arena instead of a file that you know to be generated during `configure` already. (The off-source configure is also used in some companies with a readonly mounted source repository - only in the $builddir you can write any file anyway). As a side-effect: some developers assume that some directories do already exist where in they fact they do not. Well, here we can use the two helper macros AS_MKDIR_P and AS_BASENAME which emulate `mkdir -p` and `basename` in a portable fashion.

Have other ideas that are both (a) short and (b) especially useful to the casual macro writer? Please write me: <guidod@gmx.de>