Particular Programs (Automake and Autoconf Reference Manual)

8.3.2 Particular Program Checks

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

Macro: AC_PROG_AWK

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).

Macro: AC_PROG_GREP: 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.

Macro: AC_PROG_EGREP: 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.

Macro: AC_PROG_FGREP: 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.

Macro: AC_PROG_INSTALL

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 Autoconf 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 install.sh, 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 either install-sh or install.sh in your distribution; otherwise configure produces an error message saying it can’t find them—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 Makefile.in files.

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

Macro: AC_PROG_MKDIR_P

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

If flex is found, set output variable LEX to ‘flex’ and LEXLIB to -lfl, if that library is in a standard place. Otherwise set LEX to ‘lex’ and LEXLIB to -ll, if found. If neither variant is available, set LEX 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.

Define YYTEXT_POINTER if yytext defaults to ‘char *’ instead of to ‘char []’. Also set output variable LEX_OUTPUT_ROOT to the base of the file name that the lexer generates; usually lex.yy, but sometimes something else. These results vary according to whether lex or flex is being used.

You are encouraged to use Flex in your sources, since it is both more pleasant to use than plain Lex and the C source it produces is portable. In order to ensure portability, however, you must either provide a function yywrap or, if you don’t use it (e.g., your scanner has no ‘#include’-like feature), simply include a ‘%noyywrap’ statement in the scanner’s source. Once this done, the scanner is portable (unless you felt free to use nonportable constructs) and does not depend on any library. In this case, and in this case only, it is suggested that you use this Autoconf snippet:

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

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.

To ensure backward compatibility, Automake’s AM_PROG_LEX invokes (indirectly) this macro twice, which causes an annoying but benign “AC_PROG_LEX invoked multiple times” warning. Future versions of Automake will fix this issue; meanwhile, just ignore this message.

As part of running the test, this macro may delete any file in the configuration directory named lex.yy.c or lexyy.c.

The result of this test can be influenced by setting the variable LEX or the cache variable ac_cv_prog_LEX.