On Fri, 4 Mar 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <hgs@xxxxxxxxx> 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
cases.
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: <Pine.CYG.4.58.0503011720330.2840@QnexPbzzhavba>
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,
Hugh
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
