>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes:
>>>>> "AD" == Akim Demaille <[EMAIL PROTECTED]> writes:
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes:
Martin> Notice that AC_DEFINE seems to get undefined because of its
Martin> appearance in a _comment_ in AC_OUTPUT. Bizarre!
AD> No, you are abused by the error message. The message is triggered
AD> because autoconf.sh saw something which looks very much like a
AD> macro in configure (the output), via an egrep A[CHM]_. And then
AD> it reports to you what it saw pretending it was undefined.
Martin> I don't know how hard it would be to implement, but it would
Martin> be better to search for
Martin> \bAC_
Martin> since you currently get hits on XAC_DEF
I do think that indeed there was no \b because doing this portably is
a pain. But anyway we grew used to this, and have found some
advantages, such as your present case. If your macro is named
XE_AC_CHANGE_COMPLETELY_THE_INTERNALS_OF_AUTOCONF and it is not
expanded, then Autoconf will issue a complaint (with a `T', it's the
noun, not the verb :). With your change, you'll know nothing.
Martin> Even better would be to look for exact symbols in the output
Martin> that have a definition, so the word AC_ in the output would
Martin> generate no error message, while AC_DEFINE would.
s/DEFINE/DEFUN/, don't you?
Martin> And of course, you should only report hits corresponding to
Martin> the original source files.
Once tracing works, it might be doable, but currently it's overkill.
Akim
