Re: RFE: configure -> dependency list on exit.

[Dan Manthey]

On Tue, 1 Mar 2005, Paul Eggert wrote:

> For example, we could add an optional argument for AC_MSG_NOTICE, that
> says the notice should be appended to the end of the output rather
> than put into the middle.  Then the user could do something like this:
>
> AC_MSG_NOTICE([Suggestion for foo: grab the latest foo from foo.org.], 1)
> AC_MSG_NOTICE(
>   [Suggestion for libxy --with graphs: get libxy from http://sf.net/xy.], 1)
>
> As a nicety, notices at the end could be sorted by numeric value of
> the priority number.
>

        I really like this solution, but it does beg one question: is a
greater priority more urgent to report (should be reported before higher
priorities), or is it more important to make visible on the display
(should be reported after higher priorities)?
        I think if we choose the former interpretation and allow negative
values, then both ideas are captured because values of large magnitude and
positive sign have priority in the first sense, while values of large
magnitude and negative sign have priority in the second sense.

        There is the problem that this modification to AS_MSG_NOTICE does
not prevent generation of config.status.  Well, actually we could make it
do so, but that much limits the value of the more general mechanism.
Ergo, I propose AC_NONFATAL([STATUS=1]) has the effect of setting the
shell variable `ac_exit_status' (or something else *shrug*).  AC_OUTPUT
should examine this variable (which of course would start as or default to
zero) and if it is non-zero, AC_OUTPUT does not generate config.status
and terminates configure with the specified status.  I'd further suggest
that AC_NONFATAL([STATUS=1],MSG) be equivalent to

AC_NONFATAL(STATUS)
AC_MSG_NOTICE(MSG,STATUS)

Note that this has the implication that AC_NONFATAL(0,[MSG]) turns back on
config.status generation.  I feel $ac_exit_status should be part of the
public interface so as to allow general testing of it by the configure
script.

-Dan