On Mon May 20 12:01 2002 +0200, Akim Demaille wrote: > Your need is very legitimate! The main problem is that the behavior > of one such macro is very unclear, especially because there are > several possible evaluation schemes of the COMMANDS (e.g., the > compiling macros need the COMMANDS to be evaluated twice, since they > contain shell variables that must be expanded. > > I'm going to try to clear this part in Autoconf, and to provide a > definitive interface. > > As far as config.log is concerned, there was not enough demand for > such a macro: having config.log filled as a side-effect of some main > command (such as AC_RUN_COMMAND) has always been proved sufficient. > Since I'm willing to keep the interface as small as possible, it has > never been provided. > > If AC_RUN_COMMAND or similar fulfils, your needs, would that be > enough, or would you still need some form of AC_MSG_LOG?
For what I'm currently trying to do, having an AC_RUN_COMMAND macro would solve the problem. However, as you note, there are several different permutations of AC_RUN_COMMAND that might be useful, and it might be difficult to support all of them. If I had to choose between the two macros, I'd rather have an AC_LOG_MSG macro, because that's the part that I'm currently lacking an interface for. If I have AC_LOG_MSG, I can roll my own AC_RUN_COMMAND, but without AC_LOG_MSG, I have no supported interface for logging to config.log. Thanks for the response! -- Mark D. Roth <[EMAIL PROTECTED]> http://www.feep.net/~roth/
