Autoconf

In a simple application, you'd probably just add something to your Makefile's CFLAGS and LDFLAGS lines like of the following:

CFLAGS = ${CFLAGS} -I/usr/local/foobar/include LDFLAGS = ${LDFLAGS} -lfoobar -L/usr/local/foobar/lib

Anyone else building your application who doesn't have libfoobar, or has it installed in another location, would get treated to a cryptic error message and left to his own devices to determine what went wrong.

Most OSS applications developed in the past decade or soPHP includedtake advantage of a utility called autoconf to generate a complicated configure script from a set of simple macros. This generated script then does the work of looking for where those dependent libraries and their headers are installed. Based on this information, a package can customize that build line, or provide meaningful error messages before compilation time has been wasted on a configuration that won't work.

In building PHP extensions, whether or not you plan to release them to the public, you'll take advantage of this same autoconf mechanism. Even if you're already familiar with autoconf, take a minute to read through this chapter as PHP includes several custom macros not found in the usual autoconf setup.

Unlike traditional autoconf setups, where a central configure.in file at the base of the package contains all configuration macros, PHP only uses configure.in to manage the coordination of several smaller config.m4 scripts located throughout the source tree, including one for every extension, SAPI, the Core itself, and the Zend Engine.

You've already seen a very simple version of this config.m4 script in previous chapters. In the coming pages, you'll add additional autoconf syntax to this file, allowing more configuration time information to be collected by your extension.