[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Hugh Sasse Staff Elec Eng
Subject: Re: RFE: configure -> dependency list on exit.
Date: Mon, 7 Mar 2005 11:54:33 +0000 (WET)

On Fri, 4 Mar 2005, Paul Eggert wrote:

Hugh Sasse Staff Elec Eng <address@hidden> writes:

Should dependency-name be a package or a desired feature, which the
suggested package(s) support?

A feature, obviously.  But I don't see the need for dependency-name in
the first place.  I think it won't work in practice -- actual
dependencies are too messy and too informal.

It doesn't have to work for every case to be very useful in some

I think Paul's idea was to haves
         AC_MSG_NOTICE (@var{message}, @ovar{priority})
if the second argument is omited, the message is displayed immediately.
Otherwise, the message is saved for the end.

I think that is harder to understand, and this would be clearer when
reading.  For example, when hacking the texi it was pretty clear
what the @code{}, @file{} etc things did.

If you're going to have new names only, you should put the priority
as the first arg, since it's shorter.

I've lost you here: we still need to output a message, and it is not
coventional to have optional arguments first.  Optional arguments
can be left off completely.  One can default a priority easilty, it
is hard to default the message.

As long as we're being more general, perhaps the general facility should
be something like this:

AC_ATEXIT(priority, action)

That will let you do whatever you like at the end, including futz with
the exit status I suppose.  Then we wouldn't need AC_MSG_END.

I don't understand this: is the action expanded as a macro, is it
arbitrary code, or what?  I think prioritising messages makes sense:
in the end it doesn't matter as far as execution is concerned, what
order messages are output. That isn't true for executable code, some
statements must come in a particular order.  Mistakes in message
priorities would be less dangerous than mistakes in the priority of
execuatble code.

Also -- a small point -- priorities should all be positive.  (This
allows for future extension.)

Dan Manthey wrote on: Tue, 1 Mar 2005 17:38:50 -0500
with Message-ID: <address@hidden>

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

which is why I include negative numbers.  If he's prepared to forgo
this then OK.

        Thank you,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]