I've got a header in which I want to replace both #undef FOO and @foo@. 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
