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

[Hugh Sasse Staff Elec Eng]

On Tue, 22 Feb 2005, Paul Eggert wrote:

> Hugh Sasse Staff Elec Eng <address@hidden> writes:
>
> > 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.
>
> Part of the problem here is that your proposal is almost diametrically
> opposed to how Autoconf currently behaves.  Currently, Autoconf
> doesn't care about names of packages: all it cares about is which
> features are available, and which aren't, regardless of which package
> supplies the features.

I'm not opposing that searching strategy, I'm trying to make the
output informative. 
> As I understand it, you are proposing that Autoconf generate a
> component that can be used as part of a packaging strategy that is
> based on package names and versions.  From Autoconf's point of view,

No.  I'm proposing that Autoconf tell me as much as possible when
things go wrong.  "Possible" includes knowledge that the authors of a
configuration have.  "As much" includes not dying prematurely,
using dependency information to avoid (a) useless subsequent tests
and (b) the possibility of useful subsequent tests.

If that is made to work, then it may be possible to build on it, but
what I'm proposing now is not the full information for every case.
Indeed, when I was proposing the DEPENDENCIES file I was not saying
that all possibilities must be covered: just that the syntax
should support it, for the future.  Now I'm just trying to get the
proposal that configure use dependency information to avoid dying
too soon implemented.  Autoconf cannot test for versions of
packages, because there is no standard way to present this even with
a --version option.  But we can say that you need GNU m4 to build
some packages, and GNU  make to build some, etc.  So that level of
dependency information is expressible.

> this is a simplistic approach that is relatively hard to maintain --
> lots of stuff will have to be done by hand that Autoconf currently
> does automatically.  (E.g., which versions of GNU/Linux support

No, not which versions of a platform support this.  In my original
text file I was proposing version based information.  Using Autoconf
one deals with versions that are there.  If authors can tell me
which version I should get then it seems sensible to say so.  Clearly
getting all that (version information) into autoconf would not
happen, because people wouldn't do it.  But getting general
dependency information, bearing in mind that tsort et al deal with
PARTIAL orderings, can still provide useful help, even if the
information is not complete.

> clock_gettime with CLOCK_MONOTONIC?  Surely you don't want to maintain
> that sort of information by hand.  So will you have a database that
> stores this stuff automatically?  How will it be maintained, exactly?

One of the proposals was to put this in GNOWSYS, but it seems that
most of the respondents seek improvements to autoconf in this
direction, instead (or maybe as well).

> That sort of thing.)
>
> I'm not saying your idea lacks merit: there are real problems in this
> area that it would be nice to address.  However, I suspect you'll
> discover, when you try to implement the idea for Autoconf, that
> there's a reasonably large amount of thinking that needs to be done
> before the proposal would be practical.  For example, you may discover
> that you need to model features, rather than merely modeling packages

Yes, for autoconf it would have to be features, but authors could
provide informationl messages about packages when they know this and
it makes sense.

> and version numbers.  This will require some real design work, which

The original documementation proposal was for version numbers, but
clearly that is too big a task to integrate into autoconf, and may
be too brittle for it.

> will require a significant amount of time.
>
> (Perhaps I'm being overly pessimistic.  But in that case you can prove
> me wrong by supplying a working implementation with some examples of

Even that Patent Office don't make that demand except for things
which are physically impossible. :-)

> how it's used.  That would be ideal.  :-)
        Hugh