On Tue, 22 Feb 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <hgs@xxxxxxxxx> 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
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
