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

[Hugh Sasse Staff Elec Eng]

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],[http://gnu.org/whereever_flex_is.html])
> >
> > 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
> >   <http://www.gnu.org/software/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
gnu-prog-discuss.

> discussed).
>
>
> > 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 configure.ac file:
> >
> > case $my_warning in
> > ?*) AC_MSG_WARN("$my_warning");;
> > esac
>
>         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
Ruby-Talk.
> > 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

http://www.pdc.kth.se/~jas/one-long-torture.html

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
else?
> -Dan
        Thank you,
        Hugh