combining AC_DEFINE and AC_SUBST

[Dan Manthey]

I've got a header in which I want to replace both #undef FOO and @address@hidden
At the moment, I do this by

AC_CONFIG_COMMANDS(foo.h,
[$as_myself --header=-:foo.h.in | $as_myself --file=foo.h:-])

This works tolerably, but has some irritating limitations.

The most obvious one is that I'm now calling config.status three times to
generate foo.h.  If I do something like

./config.status foo.h --header=bar.h --file=baz.h

then my main run of config.status has already build all its sed scripts to
do both AC_DEFINE and AC_SUBST substitutions, but none of these are used
during the calls used to construct foo.h from foo.h.in.  First it creates
a second process that generated a second copy of the AC_DEFINE sed scripts
and then a third process with a second copy of the AC_SUBST scripts.  Ew.

Also, I'm using multiline output variables to include blocks like:

#ifndef FOO_T
#define FOO_T
typedef unsigned short foo_t;
#ifdef FOO_MAX
#undef FOO_MAX
#endif
#define FOO_MAX 0xFFFFu
#endif

Unfortunately, this means that if a were to use --file before --header, my
generated foo.h gets

/* #undef FOO_MAX */

which is not what I want.  So, I use first --header and --file, but this
means that config.status doesn't check to see if the generated foo.h is
unchanged, causing excess remaking.

One option would be for all of my AC_SUBST'ed values to use

#undef /* leave me alone, config.status! */ FOO_MAX

and then use --file before --header.  This could possibly also allow me to
hack my way around the multiple calls to config.status by (ab)using
INIT_CMDS, though I haven't looked into doing that.

Really, my question comes down to this:

(1) Is `#undef /* comment */ MACRO' portable as a way to avoid --header
mangling of `#undef MACRO'?  Do any known compilers choke on this?

(2) Clearly, there wasn't much appeal to AC_SUBST'ing a value with `#undef
MACRO' until you could AC_SUBST multiple lines (By the way, I haven't yet
posted the patch to do that because final permission has become lost
somewhere in the bowels of my company's legal department.  Gr.), but I'm
curious how much interest there is in fixing this problem.  If I'm the
only one crazy enough to use Autoconf this way, I can just live with the
slowness of my current solution.

-Dan