moving things from configure.ac to acinclude.m4

[Cliff Miller]

i am autoconfiscating (2.57) a number of packages which all use a set of
third-party libraries for which i've written AC_ARG_WITH macros.

the configure.ac files for all the packages using these libraries are
nearly identical, except for (a) the args to AC_INIT and AM_INIT_AUTOMAKE,
and (b) in a few cases, a few additional AC_CHECK invocations.

i decided that it would be less error-prone to write a macro for the
invariant piece of configure.ac which tests for the third-party libraries
(and does AC_SUBST, etc.), moving those 30 lines of tests from configure.ac
to acinclude.m4, and invoking it from configure.ac with a single macro.
thus whenever i need to update these tests, i can just re-copy acinclude.m4
into all these packages and autoreconf, rather than hand-editing every
package's configure.ac.

before:

AC_PREREQ(2.57)
AC_INIT(package,0.1)
AM_INIT_AUTOMAKE(package,0.1)
{30 lines of AC_PROG_*, AC_ARG_*, AC_CHECK_*, AC_SUBST, etc.}
AC_CONFIG_HEADERS([config.h]
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT

after:
AC_PREREQ(2.57)
AC_INIT(package,0.1)
AM_INIT_AUTOMAKE(package,0.1)
AC_CBM_LIB_TESTS
AC_CONFIG_HEADERS([config.h]
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT

[where now acinclude.m4 contains:]

AC_DEFUN(
    AC_CBM_LIB_TESTS,
    [
        {30 lines of AC_PROG_*, .... }
    ]
)

after making this change, the order of the checks in configure has
changed... in particular, it seems that AC_HEADER_STDC checks moved
practically to the top of configure, before AC_PROG_CC figures out
how to invoke gcc, so now the AC_HEADER_STDC checks fail.

even though the 30 lines of tests are in the same order in
AC_CBM_LIB_TESTS as they were in the original configure.ac file
(the code was in fact cut-and-pasted verbatim), the order of macro
expansion in the resulting configure file is different.  is there
something special about certain AC_ macros that causes their expansions
to behave differently depending on whether or not they are inside
another macro or not?  or is the issue that i pushed these calls
into acinclude.m4?  (something about diversions, i assume...?)

is this behavior documented somewhere so i can know what i can and
cannot encapsulate inside a macro and/or inside acinclude.m4?

mtia,
-cliff