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

[Hugh Sasse Staff Elec Eng]

On Tue, 22 Feb 2005, Jacob Meuser wrote:

> On Wed, Feb 23, 2005 at 01:24:06AM +0000, Hugh Sasse Staff Elec Eng wrote:
>
> > 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.
>
> careful there.  you can say only GNU m4 or GNU make will work, but
> it's quite possible some other m4 or make has picked up whatever
> extension you need.

Yes.  It may even be possible to express more detailed information.
But, IIRC, Binutils tells you exactly that you need these packages.
This information is to help people make progress.  Maybe some other
{make, m4, ld, ...} will work, but suggesting known quantities will
help the most people make progress.
> > > 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
        [...]
> > 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.
>
> it would be useful to have a way to show the user the dependency tree.
> show what is absolutely necessary, what is optional, and what options
> depend on what other options and how the dependencies relate.
>
> I don't think it's good to require packages.

I'm not suggesting *requiring* packages: I'm suggesting that the
software tells installers way(s) to proceed when something fails.
> suggesting packages that supply a feature is good though, IMHO.
Exactly.

> however, the projects that actually care about this stuff already

All of them?

> supply this information, somehow.  lots of projects don't make this
> information available.  I agree that making it easy
> and consistent would be nice.

That's what I'm trying to do.
> but I'm really against depending on packages, especially in the case
> of common base functions.  if configure tells me to install glibc,
> well, I'm not sure what I'd do.  but if it said

Well, at least you'd have a choice.
> function 'int foo(void)' not found:
>  function int foo(void) can be found in the following packages:
>    * glibc url://...
>    * dietlibc url://...

You've got what I mean.  There is no point in making configure FORCE
people to install a package, because it may not work on that
platform, but telling them what would work allows them to make
choices.

> that would be nice.
>
> --
> <address@hidden>
        Thank you,
        Hugh