On Tue, 22 Feb 2005, Bob Friesenhahn wrote:
On Tue, 22 Feb 2005, Thomas Dickey wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
A few weeks ago I wrote to the Gnu coding standards people, with a suggestion that there should be a DEPENDENCIES file, so that
It would be nice if autoconf did that for itself. I don't recall a "recent" release which satisfied that goal (and noted that problem on this mailing list several times without seeing any result).
Autoconf has no way to know anything about a "package". It works by executing the compiler/linker so it only tests the cumulative result of installing "packages".
If it is looking for headers that only GCC has, then it is looking for GCC, which means one has to install GCC. The implications are the same either way. And:
There is the potential for using a DEPENDENCIES file to display intelligent error messages. For example, failure to find a header or library could trigger a semi-intelligent message suggesting that maybe the associated package needs to be installed or updated. The suggestion message could be
Precisely.
totally wrong though, since failure to detect a header or library could actually be due to an earlier error in the configuration process (config.log needs to be carefully inspected).
Tsort. If an earlier thing fails for a given branch of dependencies then tests for things later in that branch will fail. It doesn't prevent one looking at the other branches. If you need a C compiler and you need Awk, then finding there's no C compiler doesn't prevent you telling the user they lack Awk as well. Even some progress in this direction would be a significant halp. The Pareto principle *will* apply. (See also "There's no silver bullet") Presently, many configure scripts give up when they can't find something essential, I'm saying "list all things known to be essential, at the end (where it won't have scrolled away)." Installing some of these may affect ahat is known, but often it won't. Usually the human installer can be clueful about this, once they know what things are being asked for.
Not doing this means that the computer is micro-managing the the person doing the installation. For some cases, e.g. where binary distributions are available, it may be possible to install a number of dependent packages in parallel, instead of having it serialised by running configure N times. These machines are supposed to saving us time and effort :-).
In many cases, the same header files or libraries may be delivered by multiple packages, which could be confusing.
There are basically 4 cases (for 'header' read 'library' or whatever):
The header is known to be only found in 'package' X. That is easy.
The missing header is not known about. That probably implies your application has not been built on this platform before, because the authors just expected it to be there. So why is configure looking for it?
The header is known to appear in a number of packages. So list them.
The header is known to appear in some packages, and possibly unknonwn packages. So state this. Presumably the author(s) of the package want this header for some purpose, which will determine what they expect to be there as well as it.
Bob
Hugh
_______________________________________________ Autoconf mailing list [email protected] http://lists.gnu.org/mailman/listinfo/autoconf
