[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: Fri, 25 Feb 2005 10:16:03 +0000 (WET)

On Thu, 24 Feb 2005, Dan Manthey wrote:

On Thu, 24 Feb 2005, Paul Eggert wrote:

Dan Manthey <address@hidden> writes:

AS_PACKAGE_SUGGEST([flex 2.5.x],[])

OK, but what is the practical difference between that, and something
like this?

AC_MSG_FAILURE([you need a suitable implementation of "lex" to build
  this package.  We suggest the latest stable version of flex

Hmm, the Autoconf doc PDF doesn't explicitly say what this macro
does, only describing how it is used.  Does it cause processing to
stop?  I don't want processing to stop.

        I was thinking of AS_PACKAGE_SUGGEST (which I'm sure is a bad

AC_PACKAGE_RECOMMEND, maybe, if it SUGGEST sounds too weak??

name) as simply a formatting macro.  It might be reasonable to have it as
a macro rather than simple next because it might allow collecting all such
messages into a single place (like the putative DEPENDENCIES file

which collection is what I'd like, and the other 5 people on


my_warning='you lack a suitable implementation of "lex", so you won't
   be able to build this program reliably if you modify .l files.'

and then append something like this to your file:

case $my_warning in
?*) AC_MSG_WARN("$my_warning");;

        I figured this would basically be what AC_MSG_END would do, except
possibly push it off to a file rather than a variable, in case the
contents were large (which seems more likely if the errors include long
explanations of what kind of package is needed and where to find it).

and a file allows accumulation of information, and facilitates
formatting with fmt etc, if desired|portable...

Also not having to explicitly write the case statment is good: "code
you don't write doesn't have bugs" as someone pointed out on

An advantage of this sort of approach is that one can experiment with
these ideas now, to accomplish something in this area.  That is, one

People have said that some packages already do this to some extent.

can implement them with one's own macros; they don't require any
changes to Autoconf.  Later, if the ideas work well in practice, we
can think about how to add Autoconf macros for them (perhaps simply by
incorporating the experimental macros).

        Indeed, though it is worth noting that sensible use of these ideas
may be dependent on conditional tests, which I don't think Stepan's
AC_DEFUN'ing AC_IF quite solves (as helpful as it is as an interim
solution).  It looks like Hugh would _strongly_ desire an actual macro
AC_MSG_END (even if it's as simple as Paul's code above) for the simple
fact that it would encourage use of such messages.

Yes, for that reason.  I'd also like it to be a recommended
practice. Maybe not SHOULD, or MUST, but recommended, because I have spent so long trying to find out what I need with packages,
running configure scripts more times for a give package than I care
to remember!  And someone else referred people to

as an exmaple, which doesn't describe how they managed to find out
what worked.  I don't know how to get things recommended for
autoconf practices: GNU coding standards, autoconf docs or somewhere


        Thank you,

reply via email to

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