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

[Hugh Sasse Staff Elec Eng]

On Thu, 24 Feb 2005, Paul Eggert wrote:

> 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

That's why I said "not literally".  I needed an example, so I picked
macros I could find easily for example's sake.

> 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

And these are simply symbols that refer to them.  We need some way
to refer to tests that won't take place, so why not use the same
names?  Maybe drop the AC_ if that will make m4 happier.

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

It hasn't been written yet. I don't know yet. I'm trying to work
this stuff out, to find out how one could proceed.  I started with a
proposal about documentation.  That was rejected.  I'm tnow trying
to find a way to do this, by talking to people who know it better
than I do.

> Or, if you're not familiar with Autoconf, perhaps you can give the
> specific invocations for a package that we're both familiar with.

Like what?  Let's pick something really small, so at least it can be
held in one's head.  If it's really small then if I don't know it I
could investigate it quickly.
> 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?

Yes, although I said it may be possible to put it anwywhere,
depending on how processing of configure.ac takes place.  That at
least would allow dependency information to be kept near the NEEDS
type directives.

> First in execution order of "configure"?  First in execution order for
> "Autoconf"?  Etc.

The sorting of dependencies would have to occur first so that the
code to prune unnecessary subsequent tests could be produced.
> > > 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.

Point taken.  But it does need to be backwards compatible with older
configure.ac files.
> > 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.

So which is it then?  Having to specify all 'no dependency' cases,
or having to leave them out?  I'd tend to go for having to specify
them only when default behaviour doesn't work.  At least that would
allow old configure.ac scripts to be read by a new autoconf.
> > > >    * 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

The installers would add a message (maybe as a third parmeter like I
did) to be emitted at the end of running configure, which would
explain what went wrong and why.

> (who run "configure").

People running configure would see

Checking for lex...no
Checking for flex...no
   AC_CHECK_LEX failed

       on the basis that those are the only two lexers we can check
       for, and there is a dependency we contrived (yacc) which
       required the AC_CHECK_LEX to find something.

and at the end they would see the message about needing to get flex or lex.
they would then fail to see any checks for yacc, which, for the sake
fo this example only, we declared we wouldn't test for.

In real life, one would test for yacc, as you stated above.
> 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.

The list generated at the end doesn't exist yet.  It would
effectively replace error messages, because the complaint the 5
people had was that configure doesn't keep going and save all the
pertinent information to where it won't scroll away.  The exact
format of the error message is a detail I've not fleshed out yet. 
>
Is that any better?

        Hugh