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

[Hugh Sasse Staff Elec Eng]

On Wed, 23 Feb 2005, Paul Eggert wrote:

> Hugh Sasse Staff Elec Eng <address@hidden> writes:
>
> >    * some macro such as  AC_NEEDS(Tthis, That) expresses the idea
> >      that This feature is KNOWN to depend on the existence of That
> >      feature.
>
> This is a bit vague.  Can you give some specific examples of

They'd need to refer to the other tests: for example

AC_NEEDS(AC_PROG_YACC, AC_PROG_LEX,
"A lexer, (lex or flex, perhaps) is needed for the Yacc functionality to work")


 -- obviously not literal dependence, but there's no point in using
 the yacc stuff for this package if there's no lex to underpin it.

> invocations of this macro?  For example, you might give some specific
> invocations of AC_NEEDS that are suitable for Autoconf itself.
> Also, I'd like to know exactly where these invocations of AC_NEEDS
> would go, and why.

Up front, so that the later checks can be pruned if they fail.
> >    * where such dependency is not declared, it is not assumed.to be
> >      true or false.  In essence, do as is done now to avoid breakage.
>
> But AC_NEEDS specifies only true relationships.  How does one specify

What I meant was: some things don't get checked now -- though I'm
not familiar with how this is decided.  There should be no need to
change that kind of dependency stuff since it works now.

> false relationships?  One would need some way to do that, if the
> default is that the relationship is not known.

AC_DOES_NOT_NEED or AC_NO_NEED to assert that would be a good idea.
> >    * the dependency tree thereby constructed (using topological sort)

Well, tsort.rb says "Tarjan's algorithm" -- that's what I was
thinking of.

> >      be used to prune searches for further features
> >      AND be used to search branches which can still be
> >      explored.
>
> Can you give a specific example of this, based on the example AC_NEEDS
> invocation examples suggested above?

I don't know how to give an eample of internal operation. 
Automatically skip AC_CHECK_YACC if AC_CHECK_LEX failed.

> >    * the information collected on a pass through all practical
> >      branches (pruned by known dependency information) be presented
> >      *at the end of configure's output*, in a manner which is
> >      informative as possible.  This is in order to suggest a
> >      "shopping list" to process before retrying the build.
>
> Can you show what this new output would look like, assuming the
> examples I asked for above?
A lexer, (lex or flex, perhaps) is needed for the Yacc functionality to work

> >    * A macro be provided to declare such useful information for a test
> >      that fails -- off the top of my head:
> >      AC_NEEDS_FAILURE(This, Message)
> >      or some such.
>
> Again, this is a bit vague.  I would like to see a couple of specific

Probably easier to combine it with the AC_NEEDS macro as I have
above.

> examples of invocations of this macro, and where they would go in the

At the start.  Well, unless the file is pre-processed, which it may
need to be to skip checks, in which case where wouldn't matter.

> Autoconf source code, and how the user would cause that message to

The user wouldn't, autoconf would.

> appear, and what the whole output from "configure" would look like
> when that message appears, compared to what the output would look like
> if AC_NEEDS_FAILURE wasn't invoked.

If it's combined that case won't arise, and people won't forget it.
>

        Hugh