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

[Hugh Sasse Staff Elec Eng]

On Tue, 22 Feb 2005, Bob Friesenhahn wrote:

> On Tue, 22 Feb 2005, Thomas Dickey wrote:
>
> > On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
> >
> > > A few weeks ago I wrote to the Gnu coding standards people, with a
> > > suggestion that there should be a DEPENDENCIES file, so that
> >
> > It would be nice if autoconf did that for itself.  I don't recall a 
> > "recent" release which satisfied that goal (and noted that problem on this 
> > mailing list several times without seeing any result).
>
> Autoconf has no way to know anything about a "package".  It works by 
> executing the compiler/linker so it only tests the cumulative result of 
> installing "packages".

If it is looking for headers that only GCC has, then it is looking
for GCC, which means one has to install GCC.  The implications are
the same either way.  And:
> There is the potential for using a DEPENDENCIES file to display intelligent 
> error messages.  For example, failure to find a header or library could 
> trigger a semi-intelligent message suggesting that maybe the associated 
> package needs to be installed or updated.  The suggestion message could be

Precisely.

> totally wrong though, since failure to detect a header or library could 
> actually be due to an earlier error in the configuration process (config.log 
> needs to be carefully inspected).

Tsort.  If an earlier thing fails for a given branch of dependencies
then tests for things later in that branch will fail.  It doesn't
prevent one looking at the other branches. If you need a C compiler
and you need Awk, then finding there's no C compiler doesn't prevent
you telling the user they lack Awk as well.  Even some progress in
this direction would be a significant halp.  The Pareto principle
*will* apply. (See also "There's no silver bullet")  Presently, many
configure scripts give up when they can't find something essential,
I'm saying "list all things known to be essential, at the end (where
it won't have scrolled away)."  Installing some of these may affect
ahat is known, but often it won't.  Usually the human installer can
be clueful about this, once they know what things are being asked
for.

Not doing this means that the computer is micro-managing the the
person doing the installation.  For some cases, e.g. where binary
distributions are available, it may be possible to install a number
of dependent packages in parallel, instead of having it serialised
by running configure N times.  These machines are supposed to saving
us time and effort :-).

> In many cases, the same header files or libraries may be delivered by 
> multiple packages, which could be confusing.

There are basically 4 cases (for 'header' read 'library' or whatever):

The header is known to be only found in 'package' X.  That is easy.

The missing header is not known about.  That probably implies your
application has not been built on this platform before, because the
authors just expected it to be there.  So why is configure looking
for it?

The header is known to appear in a number of packages. So list them.

The header is known to appear in some packages, and possibly
unknonwn packages.  So state this.  Presumably the author(s) of the
package want this header for some purpose, which will determine what
they expect to be there as well as it.

> Bob

        Hugh