On Wed, Feb 23, 2005 at 01:24:06AM +0000, Hugh Sasse Staff Elec Eng wrote:
> 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.
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.
> >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.
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.
suggesting packages that supply a feature is good though, IMHO.
however, the projects that actually care about this stuff already
supply this information, somehow. lots of projects don't make this
information available. I agree that making it easy
and consistent would be nice.
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
function 'int foo(void)' not found:
function int foo(void) can be found in the following packages:
* glibc url://...
* dietlibc url://...
that would be nice.
--
<jakemsr@xxxxxxxxxxx>
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
