On Wed, 23 Feb 2005, Paul Eggert wrote:
Hugh Sasse Staff Elec Eng <hgs@xxxxxxxxx> writes:
* some macro such as AC_NEEDS(Tthis, That) expresses the idea that This feature is KNOWN to depend on the existence of That feature.
This is a bit vague. Can you give some specific examples of
They'd need to refer to the other tests: for example
AC_NEEDS(AC_PROG_YACC, AC_PROG_LEX, "A lexer, (lex or flex, perhaps) is needed for the Yacc functionality to work")
-- obviously not literal dependence, but there's no point in using the yacc stuff for this package if there's no lex to underpin it.
invocations of this macro? For example, you might give some specific invocations of AC_NEEDS that are suitable for Autoconf itself. Also, I'd like to know exactly where these invocations of AC_NEEDS would go, and why.
Up front, so that the later checks can be pruned if they fail.
* where such dependency is not declared, it is not assumed.to be true or false. In essence, do as is done now to avoid breakage.
But AC_NEEDS specifies only true relationships. How does one specify
What I meant was: some things don't get checked now -- though I'm not familiar with how this is decided. There should be no need to change that kind of dependency stuff since it works now.
false relationships? One would need some way to do that, if the default is that the relationship is not known.
AC_DOES_NOT_NEED or AC_NO_NEED to assert that would be a good idea.
* the dependency tree thereby constructed (using topological sort)
Well, tsort.rb says "Tarjan's algorithm" -- that's what I was thinking of.
be used to prune searches for further features AND be used to search branches which can still be explored.
Can you give a specific example of this, based on the example AC_NEEDS invocation examples suggested above?
I don't know how to give an eample of internal operation. Automatically skip AC_CHECK_YACC if AC_CHECK_LEX failed.
* the information collected on a pass through all practical branches (pruned by known dependency information) be presented *at the end of configure's output*, in a manner which is informative as possible. This is in order to suggest a "shopping list" to process before retrying the build.
Can you show what this new output would look like, assuming the examples I asked for above?
A lexer, (lex or flex, perhaps) is needed for the Yacc functionality to work
* A macro be provided to declare such useful information for a test that fails -- off the top of my head: AC_NEEDS_FAILURE(This, Message) or some such.
Again, this is a bit vague. I would like to see a couple of specific
Probably easier to combine it with the AC_NEEDS macro as I have above.
examples of invocations of this macro, and where they would go in the
At the start. Well, unless the file is pre-processed, which it may need to be to skip checks, in which case where wouldn't matter.
Autoconf source code, and how the user would cause that message to
The user wouldn't, autoconf would.
appear, and what the whole output from "configure" would look like when that message appears, compared to what the output would look like if AC_NEEDS_FAILURE wasn't invoked.
If it's combined that case won't arise, and people won't forget it.
Hugh
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
