All of these answers are about autoconf
which is a GNU tool. However, configure
shell scripts have been in UNIX long before GNU and can be created by hand or in other ways.
What does configure do?
configure
is a just shell script. It's job is to generate a list of configuration variables that the makefile needs to build the software on that particular system. For example, it might determine the linker flags and header search paths needed to include a specific library.
configure
can also accept options from the user, for example to control whether to build in debug or release mode.
Typically configure
writes these variables to a file called config.mk
which is included by the makefile
. It may also generate a header config.h
with some preprocessor defines. Note that configure is just a helpful automation for producing this. The user can always just hand edit config.mk
themselves (especially on obscure systems).
How does configure detect features?
configure
uses a variety of techniques to locate dependencies and detect system or hardware features. The least stable (but sometimes necessary way) is to check the uname
to detect and operating system. One useful tool is pkg-config
which can tell you where to find various installed libraries.
Lastly, configure scripts can always generate small snippets of code, and then trying to compile them to see if a feature is available.
Joe Nelson has a great article with examples for each of these ideas.
Should I write my own configure or use autoconf?
Most programs only have 1 or 2 small things they need to detect to get working. I think it makes sense to write a configure script in these cases, rather than try to figure out corner cases of the massive piece of software that is autotools. If you product a simple config.mk
it can always be fixed by hand, and users of various systems will be helpful in getting your configure
to work correctly.
For more complex dependencies, autoconf
is probably useful.
To be fair to all parties, let's relate the argument made in autoconf
's documentation:
The primary goal of Autoconf is making the user’s life easier; making the maintainer’s life easier is only a secondary goal.
Autoconf is highly successful at its goal—most complaints to the Autoconf list are about difficulties in writing Autoconf input, and not in the behavior of the resulting configure. Even packages that don’t use Autoconf will generally provide a configure script, and the most common complaint about these alternative home-grown scripts is that they fail to meet one or more of the GNU Coding Standards (see Configuration in The GNU Coding Standards) that users have come to expect from Autoconf-generated configure scripts.
To summarize:
- your configure might not have all the commands some users expect.
- You might detect features incorrectly or using incorrect assumptions for example
if macOS { use mac commands } else { use linux commands }
, instead of if gnuTools { use gnu commands } else { use bsd/posix commands }
.
You will have to determine whether that's important to you.