autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hugh Sasse Staff Elec Eng
Subject: Re: RFE: configure -> dependency list on exit.
Date: Tue, 22 Feb 2005 19:27:28 +0000 (WET)

On Tue, 22 Feb 2005, Paul Eggert wrote:

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

This message is a request to implement the suggestion that configure
produce a listing, when it finishes, of the packages needed to build
this package

That would be a nice thing to have, but I don't see how to implement
it easily.  Perhaps you can suggest how to do it?  (The best way to
suggest it is to propose a patch.  :-)

I did suggest a patch, orignially, to the GNU Coding Standards. This
resulted in 5 people on gnu-prog-discuss telling me that autoconf
should be modified instead.

I think that at present there is no structured dependency
information in the ac files from which configure and so on are
built.  I would suggest that some directives for expressing
dependencies be added, so that tsort could be used to determine the
branching structure of dependencies.  For exmple, you could look at
Rake, or if you are not into Ruby, then Make.  I think you only need
a directive like

NEEDS(A,B)

so that A becomes less than B.  Or call it DEPENDS_ON(A,B).
If B, C, and D are needed for A then we don't kneed more than
two parameters, we can do things like:
NEEDS(A,B)
NEEDS(A,C)
NEEDS(A,D)
NEEDS(D,B)

to express what make would call

D: B

A: B C D

So one could use topological sorting to organise the dependencies
into branches, so one could work out what is absolutely needed to
build each branch.  This code is almost certainly lurking in GNU
Make.

This would at least allow the pruning of branches that cannot be
investigated further, instead of assuming that all branches cannot
be investigated further, when soemthing fails. In the above case, if
B fails we can't investigate D, but if C fails we could.

Then, one might add a directive to tell the user what to install if
something fails.  But even without this it would still be an
improvement on the cases where early failure results in information
loss.

As to my providing patches for this: well, if I was familiar with
the internals, then it would be practical for me to do that.

        Hugh




reply via email to

[Prev in Thread] Current Thread [Next in Thread]