Hi Patrick, * Patrick Welche wrote on Wed, Jun 03, 2009 at 11:36:17AM CEST: > On Fri, Mar 21, 2008 at 10:29:05AM -0400, Stefan Seefeld wrote: > > I'm trying to use AC_PROG_LEX to discover whether flex (or lex) is > > available. During testing I found out that, even when neither is > > available, the LEX variable is set to ':' instead of being empty. > > And sure enough, I subsequently found this in the programs.m4 code: > > > > > > AC_DEFUN_ONCE([AC_PROG_LEX], > > [AC_CHECK_PROGS(LEX, flex lex, :) > > if test "x$LEX" != "x:"; then > > _AC_PROG_LEX_YYTEXT_DECL > > fi]) > > > > Is this intentional ? Is it documented somewhere ? In other words, is it > > ok for me to check for "test $LEX != ':'" to discover success ? Hmm. I'd probably say that would be ok. Not because I think it is a good idea to document that LEX is set to ':' when not found, but because I think we cannot change that anyway because software relies on it. When looking at the semantics of program searches in case of failure, we have been using different fallback values, typically in a way that suited the primary intended use. For example, the intention here is that packages using autotools (i.e., also Automake) will ship the files generated by (f)lex alongside the .l file, so if the user happens to not have flex or lex installed, that is no big issue, and ':' will do the job of not touching the file and also allowing 'make' to succeed. With some other tools, we choose 'false' if they are not present because we want builds to generally fail without them. So, if Eric wants to adjust the documentation to reflect the ':' value of LEX here, I'd be fine with that. > While here, I just hit the following problem: > > User has old flex in /usr/bin/flex, and new flex in /usr/local/bin, > so calls "./configure LEX=/usr/local/bin/flex" to configure the > program which needs new flex. The problem is that AC_PROG_FLEX's > description is > > If `flex' is found, set output variable `LEX' to `flex'... > > so the program's configure.ac tests > > if test "$LEX" != flex; then > > as a way of testing flex vs lex, and decides that there is no flex. > > So, essentially, $LEX is being used for two things: "this is where my > lexer lives" and "this is real flex". I wouldn't read it that way. Agreed, the documentation is terse, but it's not wrong: LEX is set to flex if flex is found (note I'm using if not iff a.k.a. if and only if). If the user overrides LEX, well, then the configure test does not search, so in some sense, there is no "found" there either (way to go splitting hairs...) I think we should adjust the documentation to be clearer. You could use case $LEX in flex | flex$EXEEXT | */flex | */flex$EXEEXT ) ... ;; esac then but of course the user could still fool you by adding a wrapper script for a non-flex lex or some other program. Thus I think the configure.ac test should just try to execute `$LEX --version' or look for some needed option in the --help output or so. Suggestions for the doc change welcome. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
