Next: , Up: Alternative Programs   [Contents][Index]

5.2.1 Particular Program Checks

These macros check for particular programs—whether they exist, and in some cases whether they support certain features.


Check for gawk, mawk, nawk, and awk, in that order, and set output variable AWK to the first one that is found. It tries gawk first because that is reported to be the best implementation. The result can be overridden by setting the variable AWK or the cache variable ac_cv_prog_AWK.

Using this macro is sufficient to avoid the pitfalls of traditional awk (see Limitations of Usual Tools).


Look for the best available grep or ggrep that accepts the longest input lines possible, and that supports multiple -e options. Set the output variable GREP to whatever is chosen. See Limitations of Usual Tools, for more information about portability problems with the grep command family. The result can be overridden by setting the GREP variable and is cached in the ac_cv_path_GREP variable.


Check whether $GREP -E works, or else look for the best available egrep or gegrep that accepts the longest input lines possible. Set the output variable EGREP to whatever is chosen. The result can be overridden by setting the EGREP variable and is cached in the ac_cv_path_EGREP variable.


Check whether $GREP -F works, or else look for the best available fgrep or gfgrep that accepts the longest input lines possible. Set the output variable FGREP to whatever is chosen. The result can be overridden by setting the FGREP variable and is cached in the ac_cv_path_FGREP variable.


Set output variable INSTALL to the name of a BSD-compatible install program, if one is found in the current PATH. Otherwise, set INSTALL to ‘dir/install-sh -c’, checking the directories specified to AC_CONFIG_AUX_DIR (or its default directories) to determine dir (see Output). Also set the variables INSTALL_PROGRAM and INSTALL_SCRIPT to ‘${INSTALL}’ and INSTALL_DATA to ‘${INSTALL} -m 644’.

@INSTALL@’ is special, as its value may vary for different configuration files.

This macro screens out various instances of install known not to work. It prefers to find a C program rather than a shell script, for speed. Instead of install-sh, it can also use, but that name is obsolete because some make programs have a rule that creates install from it if there is no makefile. Further, this macro requires install to be able to install multiple files into a target directory in a single invocation.

Autoconf comes with a copy of install-sh that you can use. If you use AC_PROG_INSTALL, you must include install-sh in your distribution; otherwise autoreconf and configure will produce an error message saying they can’t find it—even if the system you’re on has a good install program. This check is a safety measure to prevent you from accidentally leaving that file out, which would prevent your package from installing on systems that don’t have a BSD-compatible install program.

If you need to use your own installation program because it has features not found in standard install programs, there is no reason to use AC_PROG_INSTALL; just put the file name of your program into your files.

The result of the test can be overridden by setting the variable INSTALL or the cache variable ac_cv_path_install.


Set output variable MKDIR_P to a program that ensures that for each argument, a directory named by this argument exists, creating it and its parent directories if needed, and without race conditions when two instances of the program attempt to make the same directory at nearly the same time.

This macro uses the ‘mkdir -p’ command if possible. Otherwise, it falls back on invoking install-sh with the -d option, so your package should contain install-sh as described under AC_PROG_INSTALL. An install-sh file that predates Autoconf 2.60 or Automake 1.10 is vulnerable to race conditions, so if you want to support parallel installs from different packages into the same directory you need to make sure you have an up-to-date install-sh. In particular, be careful about using ‘autoreconf -if’ if your Automake predates Automake 1.10.

This macro is related to the AS_MKDIR_P macro (see Programming in M4sh), but it sets an output variable intended for use in other files, whereas AS_MKDIR_P is intended for use in scripts like configure. Also, AS_MKDIR_P does not accept options, but MKDIR_P supports the -m option, e.g., a makefile might invoke $(MKDIR_P) -m 0 dir to create an inaccessible directory, and conversely a makefile should use $(MKDIR_P) -- $(FOO) if FOO might yield a value that begins with ‘-’. Finally, AS_MKDIR_P does not check for race condition vulnerability, whereas AC_PROG_MKDIR_P does.

@MKDIR_P@’ is special, as its value may vary for different configuration files.

The result of the test can be overridden by setting the variable MKDIR_P or the cache variable ac_cv_path_mkdir.

Macro: AC_PROG_LEX (options)

Search for a lexical analyzer generator, preferring flex to plain lex. Output variable LEX is set to whichever program is available. If neither program is available, LEX is set to ‘:’; for packages that ship the generated file.yy.c alongside the source file.l, this default allows users without a lexer generator to still build the package even if the timestamp for file.l is inadvertently changed.

The name of the program to use can be overridden by setting the output variable LEX or the cache variable ac_cv_prog_LEX when running configure.

If a lexical analyzer generator is found, this macro performs additional checks for common portability pitfalls. If these additional checks fail, LEX is reset to ‘:’; otherwise the following additional macros and variables are provided.

Preprocessor macro YYTEXT_POINTER is defined if the lexer skeleton, by default, declares yytext as a ‘char *’ rather than a ‘char []’.

Output variable LEX_OUTPUT_ROOT is set to the base of the file name that the lexer generates; this is usually either lex.yy or lexyy.

If generated lexers need a library to work, output variable LEXLIB is set to a link option for that library (e.g., -ll), otherwise it is set to empty.

The options argument modifies the behavior of AC_PROG_LEX. It should be a whitespace-separated list of options. Currently there are only two options, and they are mutually exclusive:


Indicate that the library in LEXLIB needs to define the function yywrap. If a library that defines this function cannot be found, LEX will be reset to ‘:’.


Indicate that the library in LEXLIB does not need to define the function yywrap. configure will not search for it at all.

Prior to Autoconf 2.70, AC_PROG_LEX did not take any arguments, and its behavior was different from either of the above possibilities: it would search for a library that defines yywrap, and would set LEXLIB to that library if it finds one. However, if a library that defines this function could not be found, LEXLIB would be left empty and LEX would not be reset. This behavior was due to a bug, but several packages came to depend on it, so AC_PROG_LEX still does this if neither the yywrap nor the noyywrap option is given.

Usage of AC_PROG_LEX without choosing one of the yywrap or noyywrap options is deprecated. It is usually better to use noyywrap and define the yywrap function yourself, as this almost always renders the LEXLIB unnecessary.

Caution: As a side-effect of the test, this macro may delete any file in the configure script’s current working directory named lex.yy.c or lexyy.c.

Caution: Packages that ship a generated lex.yy.c cannot assume that the definition of YYTEXT_POINTER matches the code in that file. They also cannot assume that LEXLIB provides the library routines required by the code in that file.

If you use Flex to generate lex.yy.c, you can work around these limitations by defining yywrap and main yourself (rendering -lfl unnecessary), and by using either the --array or --pointer options to control how yytext is declared. The code generated by Flex is also more portable than the code generated by historical versions of Lex.

If you have used Flex to generate lex.yy.c, and especially if your scanner depends on Flex features, we recommend you use this Autoconf snippet to prevent the scanner being regenerated with historical Lex:

if test "x$LEX" != xflex; then
  LEX="$SHELL $missing_dir/missing flex"
  AC_SUBST([LEXLIB], [''])

The shell script missing can be found in the Automake distribution.

Remember that the user may have supplied an alternate location in LEX, so if Flex is required, it is better to check that the user provided something sufficient by parsing the output of ‘$LEX --version’ than by simply relying on test "x$LEX" = xflex.


If ‘ln -s’ works on the current file system (the operating system and file system support symbolic links), set the output variable LN_S to ‘ln -s’; otherwise, if ‘ln’ works, set LN_S to ‘ln’, and otherwise set it to ‘cp -pR’.

If you make a link in a directory other than the current directory, its meaning depends on whether ‘ln’ or ‘ln -s’ is used. To safely create links using ‘$(LN_S)’, either find out which form is used and adjust the arguments, or always invoke ln in the directory where the link is to be created.

In other words, it does not work to do:

$(LN_S) foo /x/bar

Instead, do:

(cd /x && $(LN_S) foo bar)

Set output variable RANLIB to ‘ranlib’ if ranlib is found, and otherwise to ‘:’ (do nothing).


Set output variable SED to a Sed implementation that conforms to Posix and does not have arbitrary length limits. Report an error if no acceptable Sed is found. See Limitations of Usual Tools, for more information about portability problems with Sed.

The result of this test can be overridden by setting the SED variable and is cached in the ac_cv_path_SED variable.


If bison is found, set output variable YACC to ‘bison -y’. Otherwise, if byacc is found, set YACC to ‘byacc’. Otherwise set YACC to ‘yacc’. The result of this test can be influenced by setting the variable YACC or the cache variable ac_cv_prog_YACC.

Next: , Up: Alternative Programs   [Contents][Index]