On Tue, 22 Feb 2005, Bob Friesenhahn wrote:
On Tue, 22 Feb 2005, Hugh Sasse Staff Elec Eng wrote:
I think that at present there is no structured dependency information in the ac files from which configure and so on are built. I would suggest that some directives for expressing dependencies be added, so that tsort could be used to determine the branching structure of dependencies. For exmple, you could look at Rake, or if you are not into Ruby, then Make. I think you only need a directive like
This suggests that autoconf should artificially constrain the available
No: it should express the existing constraints, where they are known.
options or that packages should necessarily be aware of the available
Should, but not MUST: If an author knows what the constraints are, express this so the system can tell the user|installer.
options, or that tested features should exist. If vsnprintf is tested for but is not found by default, what should autoconf do? Should it demand that vsnprintf be provided by a particular "package" and quit? Or should the
If it is known to be provided by a package, suggest that package. It should not quit: it should look for other things it needs. Then list the info before exiting.
configure script simply record that the function is not available and the app
record it to announce at the end and move on...
can deal with that in some other way?
That is still possible: I'm only trying to get existing known dependecies expressed. If compiler directives in the code like #ifdef HAS_VNSPRINTF #endif can do useful work, by all means do that. I'm saying that the author is likely to know where to get vnsprintf, and if they do they should say so. The fallback case is things fail, like they would now.
Bob
Hugh
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
