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

[Paul Eggert]

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

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

Sorry, I don't understand this example.  First, as a technical matter,
one does not need Yacc functionality to use Lex.  Second, and more
important, AC_PROG_YACC and AC_PROG_LEX are currently simply macros
that test for features: they (a) do not need each other, in order to
operate, and (b) are not features in themselves, so they aren't
suitable as operands for AC_NEEDS as I understand you.  But it sounds
like I may not be understanding you yet.

>> 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.

But what are the _specific_ invocations of AC_NEEDS for Autoconf?
Or, if you're not familiar with Autoconf, perhaps you can give the
specific invocations for a package that we're both familiar with.

Also, "up front" is a bit vague.  (Everybody always wants their stuff
to be done first.  :-) Where exactly is "up front"?  This will help me
understand what exactly do you mean by "up front": Textually first?
First in execution order of "configure"?  First in execution order for
"Autoconf"?  Etc.

>> 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.

Sorry, this won't work.  If there are three answers to the question
"Does X depend on Y?" (yes, no, I don't know) then we must provide a
way for users to specify these three answers.  If we let them specify
only "yes" answers, and default to "I don't know", then there's no way
for them to specify a "no" answer.

> AC_DOES_NOT_NEED or AC_NO_NEED to assert that would be a good idea.

But that won't work very well.  If we have (say) 1000 features to
specify -- which is not an unreasonable number for real-world projects
-- then we'll need to have about 1,000,000 AC_NO_NEED calls.

>>
>>>    * the dependency tree thereby constructed (using topological sort)
>>>      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.

I wasn't asking for the internal details; I was asking for how this
would work, specifically, from the users' point of view.  Here the
users are the developers (who specify AC_NEEDS) and the installers
(who run "configure").

I am asking for which specific lines would have to be added to
configure.ac for Autoconf itself (or some other package, if you
prefer), and how this would change the behavior of "configure" (i.e.,
which lines of output it would generate in some common scenarios).  If
we can't arrive at least tentative answers to these kinds of
questions, we can't really proceed.  And I'm afraid that I can't do
this for you, since I don't really know what you want.