On Tue, Aug 19, 2008 at 17:37, Bob Friesenhahn <bfriesen@xxxxxxxxxxxxxxxxxxx > wrote: > On Tue, 19 Aug 2008, Allan Clark wrote: > > Heh. Jokes aside, I figured there's a good chance that the same "project" > (ie http://freshmeat.net/projects/{PROJECT}<http://freshmeat.net/projects/%7BPROJECT%7D>or http:// > {PROJECT}.sf.net/) > provides the same deliverables cross-platform. For example, the libz on > Solaris, Redhat, UNIX, and BeOS probably comes from project "libz", and so > "libz" or the URL to a libz-maintained translation (ie > http://freshmeat.net/projects-xml/zlib/zlib.xml ): > > Unfortunately there are many other factors beyond where the most recent > version of the package came from. Often a particular version of the package > is needed, that package needs to be built with certain other packages, and > certain options and compilation flags need to be used. > > If humans have extreme difficulty understanding this stuff, it is difficult > to imagine how it can be automated by a simple shell script. > > Freshmeat is a commercial enterprise which may go away tomorrow or be > purchased by Grim Reaper, Inc., so it should not be referenced by a GNU > tool. The FSF maintains its own list of software so that one might be a > better one to refer to. I thought we were shooting for the general case, not corner-cases -- "zlib" on most platforms tends to have the same build options, but users would still have to hunt down "Festival with the Ogg Codex" or whatever corner-cases and one-offs exist. This kind of thing might actually reduce corner-cases, if your optimism is the same flavour as mine. Exploiting what *is* available today (ie the still-free-for-all Freshmeat) gives a better chance of greater-than-zero functionality for these more common cases, from which we can narrow the shorter FSF list *when* existing capabilities disappear, a phased deliverable that offers potential for iterative improvement. The alternative is the all-or-nothing HURD -- which I haven't checked on recently, but I recall it had an all-or-nothing limitation. I would prefer contingencies for disappearing resources rather than the dependency on a guaranteed-forever-free resource that would need to be improved. Note also that I mention the possibility of a project-specific file -- see "autoconf.xml" above. This would be just as free as the software it describes, but would be new work on a distributed effort to a new spec. I therefore urge you to reconsider using existing resources for more common cases rather than serial dependencies on new, undiscovered data and 100% coverage which might be too difficult to reach. Allan _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
