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

[Hugh Sasse Staff Elec Eng]

On Wed, 23 Feb 2005, Paul Eggert wrote:

> Perhaps you can flesh it out a bit more by saying exactly what
> should go into the DEPENDENCIES file for Autoconf itself, and
> what "configure" should do in some common cases.  To be honest,
> I still don't really understand what you're proposing.

I'm sorry,  I thought providing the background was the best way to be
clear about where I am now.  So:

I am proposing that:

  * the configure scripts created by autoconf test for features as
    they do now.

  * some macro such as  AC_NEEDS(Tthis, That) expresses the idea
    that This feature is KNOWN to depend on the existence of That
    feature.

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

  * 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. (You can still test
    awk and perl branches if the compiler stuff fails, for example)

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

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

Things NOT proposed (but in the original documentation scheme, which
was rejected in the end):

  X  A pagaging system as part of Autoconf.
        Far too big a change, will break many things.

  X  Versioning Information for everything, including the operating
     system.
        The documentation was to be designed to facilitate that
        where it made sense, but the information explosion would
        slow down configure.  People would hate it and not maintain
        it, it seems.  Maybe people will want to add support for
        versioning later, but that's another can of worms.

  X  all dependencies be determined for all cases. (not in the
     original proposal either.)
        would never happen. because it's too much work all at once.
        If the system is found to be useful, people will be inclined
        to add bits of information here and there.  If it is not
        useful it will disappear like Chill did from GCC.

Thus this boils down to 3 things:
   two macros to support this
   one difficult part: building the depedency tree given the
   dependency inforaation, and traversing it sensibly.

So, hopefully this is clearer, and more modest than the
documentation system I was proposing.

        Hugh