On Thu, 24 Feb 2005, Hugh Sasse Staff Elec Eng wrote: > On Thu, 24 Feb 2005, Dan Manthey wrote: > > > AC_MSG_END([A lexer is needed for yacc.] > > AS_PACKAGE_SUGGEST([flex 2.5.x],[http://gnu.org/whereever_flex_is.html]) > > AS_PACKAGE_SUGGEST([lex])) > > [OT] I don't understand this extra ')' but ... Closes the one opening AC_MSG_END. The formatted result output by AS_PACKAGE_SUGGEST is part of what to report at the end of the configure run. > I like this, it is clear. Could the shell logic be produced by a > Macro, though, to help people get it right? Actually, we've already got AS_IF (That's (A) for Autoconf and (S) for shell, not "as _if_! duh!".), but using that may conflict with part of the proposal for conditional macros; don't know yet. > > file which is later output), and possibly AS_PACKAGE_SUGGEST, a fascility > > quite orthogonal to the logic that determines which tests are run. It > > would have the job of appropriately describing a recommended place to get > > a package. This could (possibly) do anything from simple string > > formatting to some sort of database lookup. > > Yes, that would be a good addition, though I think it will meet > resistance because of the documentation overhead. Anwyway, having > it as a standard macro allows future flexibility, such as the Free > Software Directory adopting GNOWSYS or enquiring of some future vast > artificial intelligence :-). Frankly, I think I'd resist it, but it seemed to be what you were asking for. > I don't think we need to generate a DEPENDENCIES file, although it > would be nice to generate supporting documentation automatically. Here I have to side with Paul and ask exactly what you mean by that. > I think that provided the AS_MSG_END macro produces a clear message > with dependency information when configure is run, and does so at > the end as you say, this would be a very significant improvement. > > > > I'm not convinced that the dependencies are complex enough to need > > anything more than sane use of if-else, but in the few cases where it is, > > that can be expressed with the form of AC_REQUIRE that takes code to > > execute as well as an identifier to have provided: > > > > AC_DEFUN([AC_PROG_YACC_THAT_NEEDS_LEX], > > [AC_REQUIRE([_YACC_CHECK_LEX], > > [AC_PROG_LEX > > if test $LEX = :; then > > AC_MSG_END([Yacc needs lex]) > > fi]) > > if test $LEX != :; then > > AC_PROG_YACC > > fi]) > > > > If the case for a failure is always a : (nicely a NO-OP in ksh at Sadly, no. That's the particular behavior of AC_PROG_LEX. I would presume that it's so that future calls of `$LEX foo.l' don't puke. > least, and, it seems, bash) then there is scope for something like Yes, : is the sh-standard no-op. > #define AC_IF_FAILED(LEX) if test $LEX != :; then > #define AC_ELSE_FAILED(LEX) else > #define AC_END_FAILED(LEX) fi No no no no, that's hideous. AS_IF([test $LEX != :],true-case,false-case) You need to have the caller specify `test' so they can use other tests, too, e.g. grep a file. > Thank you. I think you have cut through a lot of the confusion that > was springing up. I like it when people manage to simplify things > so neatly. Well, let's see if it helped Paul at all. -Dan _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf