Re: Inconsistency w.r.t. defining the same symbol more than once

[Stepan Kasal]

Hello,

On Mon, Oct 09, 2006 at 07:24:47AM -0400, Thomas Dickey wrote:
> [...], why isn't it documented?

this is the easier of your questions:

The behaviour is not part of the documented interface, because we do not want
to commit it.  IOW, we do not want to guarantee that a future version of
Autoconf will have the same behaviour.

Does this present a problem for you?

Let me give some details.

Why we decided this way:
1) The bug you reported was present in Autoconf for many years and
no one has reported it.  So it seems that the feature is not used.
2) The feature is not fully implemented, as you noticed: DEFS has all
instances, not only the last one.

OTOH, this behaviour was always mentioned as a comment in the source:
In Autoconf 2.59:
# If some macros were called several times there might be several times
# the same #defines, which is useless.  Nevertheless, we may not want to
# sort them, since we want the *last* AC-DEFINE to be honored.

In Autoconf 2.60:
dnl ac_dD used to contain `;t' at the end, but that was both slow and incorrect.
dnl 1) Since the script must be broken into chunks containing 100 commands,
dnl the extra command meant extra calls to sed.
dnl 2) The code was incorrect: in the unusual case where a symbol has multiple
dnl different AC_DEFINEs, the last one should be honored.
dnl
dnl ac_dB works because every line has a space appended.  ac_dD reinserts
dnl the space, because some symbol may have been AC_DEFINEd several times.

> On Mon, 9 Oct 2006, Stepan Kasal wrote:
> >But even though the fix was intentional, this behaviour is still
> >undocumented, so the more important part of the answer is what Paul
> >said: do not do that.
> 
> If it was intentional, and (presumably, unless someone's doing poor work) 
> appears in the changelog, why isn't it documented?

The corresponding ChangeLog entry is this:

2005-06-06  Stepan Kasal  <address@hidden>

        * lib/autoconf/status.m4 (_AC_OUTPUT_HEADERS): Simplify the sed
          scripts created and the loop applying them, use _AC_SED_CMD_LIMIT.

The motivation for the change was to save a few commands in the
generated sed script.  The bug fix was only a side effect, I mentioned it
in a comment in a code.  But since I had no clue that this might be
a real-world problem, I did not bother to mention it in the ChangeLog.

Hope this explains the situation,
        Stepan Kasal