autoconf 英文手册
1 Introduction
A physicist, an engineer, and a computer scientist were discussing the
nature of God. “Surely a Physicist,” said the physicist, “because
early in the Creation, God made Light; and you know, Maxwell's
equations, the dual nature of electromagnetic waves, the relativistic
consequences...” “An Engineer!,” said the engineer, “because
before making Light, God split the Chaos into Land and Water; it takes a
hell of an engineer to handle that big amount of mud, and orderly
separation of solids from liquids...” The computer scientist
shouted: “And the Chaos, where do you think it was coming from, hmm?”
—Anonymous
Autoconf is a tool for producing shell scripts that automatically configure software source code packages to adapt to many kinds of Posix-like systems. The configuration scripts produced by Autoconf are independent of Autoconf when they are run, so their users do not need to have Autoconf.
The configuration scripts produced by Autoconf require no manual user intervention when run; they do not normally even need an argument specifying the system type. Instead, they individually test for the presence of each feature that the software package they are for might need. (Before each check, they print a one-line message stating what they are checking for, so the user doesn't get too bored while waiting for the script to finish.) As a result, they deal well with systems that are hybrids or customized from the more common Posix variants. There is no need to maintain files that list the features supported by each release of each variant of Posix.
For each software package that Autoconf is used with, it creates a configuration script from a template file that lists the system features that the package needs or can use. After the shell code to recognize and respond to a system feature has been written, Autoconf allows it to be shared by many software packages that can use (or need) that feature. If it later turns out that the shell code needs adjustment for some reason, it needs to be changed in only one place; all of the configuration scripts can be regenerated automatically to take advantage of the updated code.
Those who do not understand Autoconf are condemned to reinvent it, poorly. The primary goal of Autoconf is making the user's life easier; making the maintainer's life easier is only a secondary goal. Put another way, the primary goal is not to make the generation of configure automatic for package maintainers (although patches along that front are welcome, since package maintainers form the user base of Autoconf); rather, the goal is to make configure painless, portable, and predictable for the end user of each autoconfiscated package. And to this degree, 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) that users have come to expect from Autoconf-generated configure scripts.
The Metaconfig package is similar in purpose to Autoconf, but the scripts it produces require manual user intervention, which is quite inconvenient when configuring large source trees. Unlike Metaconfig scripts, Autoconf scripts can support cross-compiling, if some care is taken in writing them.
Autoconf does not solve all problems related to making portable software packages—for a more complete solution, it should be used in concert with other GNU build tools like Automake and Libtool. These other tools take on jobs like the creation of a portable, recursive makefile with all of the standard targets, linking of shared libraries, and so on. See The GNU Build System, for more information.
Autoconf imposes some restrictions on the names of macros used with #if
in C programs (see Preprocessor Symbol Index).
Autoconf requires GNU M4 version 1.4.6 or later in order to generate the scripts. It uses features that some versions of M4, including GNU M4 1.3, do not have. Autoconf works better with GNU M4 version 1.4.14 or later, though this is not required.
See Autoconf 1, for information about upgrading from version 1. See History, for the story of Autoconf's development. See FAQ, for answers to some common questions about Autoconf.
See the Autoconf web page for up-to-date information, details on the mailing lists, pointers to a list of known bugs, etc.
Mail suggestions to the Autoconf mailing list. Past suggestions are archived.
Mail bug reports to the Autoconf Bugs mailing list. Past bug reports are archived.
If possible, first check that your bug is not already solved in current development versions, and that it has not been reported yet. Be sure to include all the needed information and a short configure.ac that demonstrates the problem.
Autoconf's development tree is accessible via git; see the Autoconf Summary for details, or view the actual repository. Anonymous CVS access is also available, see README for more details. Patches relative to the current git version can be sent for review to the Autoconf Patches mailing list, with discussion on prior patches archived; and all commits are posted in the read-only Autoconf Commit mailing list, which is also archived.
Because of its mission, the Autoconf package itself includes only a set of often-used macros that have already demonstrated their usefulness. Nevertheless, if you wish to share your macros, or find existing ones, see the Autoconf Macro Archive, which is kindly run by Peter Simons.
Next: Making configure Scripts, Previous: Introduction, Up: Top
2 The GNU Build System
Autoconf solves an important problem—reliable discovery of system-specific build and runtime information—but this is only one piece of the puzzle for the development of portable software. To this end, the GNU project has developed a suite of integrated utilities to finish the job Autoconf started: the GNU build system, whose most important components are Autoconf, Automake, and Libtool. In this chapter, we introduce you to those tools, point you to sources of more information, and try to convince you to use the entire GNU build system for your software.
- Automake: Escaping makefile hell
- Gnulib: The GNU portability library
- Libtool: Building libraries portably
- Pointers: More info on the GNU build system
Next: Gnulib, Up: The GNU Build System
2.1 Automake
The ubiquity of make means that a makefile is almost the only viable way to distribute automatic build rules for software, but one quickly runs into its numerous limitations. Its lack of support for automatic dependency tracking, recursive builds in subdirectories, reliable timestamps (e.g., for network file systems), and so on, mean that developers must painfully (and often incorrectly) reinvent the wheel for each project. Portability is non-trivial, thanks to the quirks of make on many systems. On top of all this is the manual labor required to implement the many standard targets that users have come to expect (make install
, make distclean
, make uninstall
, etc.). Since you are, of course, using Autoconf, you also have to insert repetitive code in your Makefile.in to recognize @CC@
, @CFLAGS@
, and other substitutions provided by configure. Into this mess steps Automake. Automake allows you to specify your build needs in a Makefile.am file with a vastly simpler and more powerful syntax than that of a plain makefile, and then generates a portable Makefile.in for use with Autoconf. For example, the Makefile.am to build and install a simple “Hello world” program might look like:
bin_PROGRAMS = hellohello_SOURCES = hello.c
The resulting Makefile.in (~400 lines) automatically supports all the standard targets, the substitutions provided by Autoconf, automatic dependency tracking, VPATH
building, and so on. make builds the hello
program, and make install
installs it in /usr/local/bin (or whatever prefix was given to configure, if not /usr/local).
The benefits of Automake increase for larger packages (especially ones with subdirectories), but even for small programs the added convenience and portability can be substantial. And that's not all...
Next: Libtool, Previous: Automake, Up: The GNU Build System
2.2 Gnulib
GNU software has a well-deserved reputation for running on many different types of systems. While our primary goal is to write software for the GNU system, many users and developers have been introduced to us through the systems that they were already using.
Gnulib is a central location for common GNU code, intended to be shared among free software packages. Its components are typically shared at the source level, rather than being a library that gets built, installed, and linked against. The idea is to copy files from Gnulib into your own source tree. There is no distribution tarball; developers should just grab source modules from the repository. The source files are available online, under various licenses, mostly GNU GPL or GNU LGPL.
Gnulib modules typically contain C source code along with Autoconf macros used to configure the source code. For example, the Gnulib stdbool
module implements a stdbool.h header that nearly conforms to C99, even on old-fashioned hosts that lack stdbool.h. This module contains a source file for the replacement header, along with an Autoconf macro that arranges to use the replacement header on old-fashioned systems.
Next: Pointers, Previous: Gnulib, Up: The GNU Build System
2.3 Libtool
Often, one wants to build not only programs, but libraries, so that other programs can benefit from the fruits of your labor. Ideally, one would like to produce shared (dynamically linked) libraries, which can be used by multiple programs without duplication on disk or in memory and can be updated independently of the linked programs. Producing shared libraries portably, however, is the stuff of nightmares—each system has its own incompatible tools, compiler flags, and magic incantations. Fortunately, GNU provides a solution: Libtool. Libtool handles all the requirements of building shared libraries for you, and at this time seems to be the only way to do so with any portability. It also handles many other headaches, such as: the interaction of Make rules with the variable suffixes of shared libraries, linking reliably with shared libraries before they are installed by the superuser, and supplying a consistent versioning system (so that different versions of a library can be installed or upgraded without breaking binary compatibility). Although Libtool, like Autoconf, can be used without Automake, it is most simply utilized in conjunction with Automake—there, Libtool is used automatically whenever shared libraries are needed, and you need not know its syntax.
Previous: Libtool, Up: The GNU Build System
2.4 Pointers
Developers who are used to the simplicity of make for small projects on a single system might be daunted at the prospect of learning to use Automake and Autoconf. As your software is distributed to more and more users, however, you otherwise quickly find yourself putting lots of effort into reinventing the services that the GNU build tools provide, and making the same mistakes that they once made and overcame. (Besides, since you're already learning Autoconf, Automake is a piece of cake.)
There are a number of places that you can go to for more information on the GNU build tools.
- Web
The project home pages for Autoconf, Automake, Gnulib, and Libtool.
- Automake Manual
See Automake, for more information on Automake.
- Books
The book GNU Autoconf, Automake and Libtool1 describes the complete GNU build environment. You can also find the entire book on-line.
Next: Setup, Previous: The GNU Build System, Up: Top
3 Making configure Scripts
- one or more Makefile files, usually one in each subdirectory of the package (see Makefile Substitutions);
- optionally, a C header file, the name of which is configurable, containing
#define
directives (see Configuration Headers); - a shell script called config.status that, when run, recreates the files listed above (see config.status Invocation);
- an optional shell script normally called config.cache (created when using ‘configure --config-cache’) that saves the results of running many of the tests (see Cache Files);
- a file called config.log containing any messages produced by compilers, to help debugging if configure makes a mistake.
Files used in preparing a software package for distribution, when using just Autoconf:
your source files --> [autoscan*] --> [configure.scan] --> configure.acconfigure.ac --.| .------> autoconf* -----> configure[aclocal.m4] --+---+| `-----> [autoheader*] --> [config.h.in][acsite.m4] ---'Makefile.in
Additionally, if you use Automake, the following additional productions come into play:
[acinclude.m4] --.|[local macros] --+--> aclocal* --> aclocal.m4|configure.ac ----'configure.ac --.+--> automake* --> Makefile.inMakefile.am ---'
Files used in configuring a software package:
.-------------> [config.cache]configure* ------------+-------------> config.log|[config.h.in] -. v .-> [config.h] -.+--> config.status* -+ +--> make*Makefile.in ---' `-> Makefile ---'
- Writing Autoconf Input: What to put in an Autoconf input file
- autoscan Invocation: Semi-automatic configure.ac writing
- ifnames Invocation: Listing the conditionals in source code
- autoconf Invocation: How to create configuration scripts
- autoreconf Invocation: Remaking multiple configure scripts
Next: autoscan Invocation, Up: Making configure Scripts
3.1 Writing configure.ac
To produce a configure script for a software package, create a file called configure.ac that contains invocations of the Autoconf macros that test the system features your package needs or can use. Autoconf macros already exist to check for many features; see Existing Tests, for their descriptions. For most other features, you can use Autoconf template macros to produce custom checks; see Writing Tests, for information about them. For especially tricky or specialized features, configure.ac might need to contain some hand-crafted shell commands; see Portable Shell Programming. The autoscan program can give you a good start in writing configure.ac (see autoscan Invocation, for more information).
Previous versions of Autoconf promoted the name configure.in, which is somewhat ambiguous (the tool needed to process this file is not described by its extension), and introduces a slight confusion with config.h.in and so on (for which ‘.in’ means “to be processed by configure”). Using configure.ac is now preferred.
- Shell Script Compiler: Autoconf as solution of a problem
- Autoconf Language: Programming in Autoconf
- Autoconf Input Layout: Standard organization of configure.ac
Next: Autoconf Language, Up: Writing Autoconf Input
3.1.1 A Shell Script Compiler
Just as for any other computer language, in order to properly program configure.ac in Autoconf you must understand what problem the language tries to address and how it does so.
The problem Autoconf addresses is that the world is a mess. After all, you are using Autoconf in order to have your package compile easily on all sorts of different systems, some of them being extremely hostile. Autoconf itself bears the price for these differences: configure must run on all those systems, and thus configure must limit itself to their lowest common denominator of features.
Naturally, you might then think of shell scripts; who needs autoconf? A set of properly written shell functions is enough to make it easy to write configure scripts by hand. Sigh! Unfortunately, even in 2008, where shells without any function support are far and few between, there are pitfalls to avoid when making use of them. Also, finding a Bourne shell that accepts shell functions is not trivial, even though there is almost always one on interesting porting targets.
So, what is really needed is some kind of compiler, autoconf, that takes an Autoconf program, configure.ac, and transforms it into a portable shell script, configure.
How does autoconf perform this task?
There are two obvious possibilities: creating a brand new language or extending an existing one. The former option is attractive: all sorts of optimizations could easily be implemented in the compiler and many rigorous checks could be performed on the Autoconf program (e.g., rejecting any non-portable construct). Alternatively, you can extend an existing language, such as the sh
(Bourne shell) language.
Autoconf does the latter: it is a layer on top of sh
. It was therefore most convenient to implement autoconf as a macro expander: a program that repeatedly performs macro expansions on text input, replacing macro calls with macro bodies and producing a pure sh
script in the end. Instead of implementing a dedicated Autoconf macro expander, it is natural to use an existing general-purpose macro language, such as M4, and implement the extensions as a set of M4 macros.
Next: Autoconf Input Layout, Previous: Shell Script Compiler, Up: Writing Autoconf Input
3.1.2 The Autoconf Language
The Autoconf language differs from many other computer languages because it treats actual code the same as plain text. Whereas in C, for instance, data and instructions have different syntactic status, in Autoconf their status is rigorously the same. Therefore, we need a means to distinguish literal strings from text to be expanded: quotation.
When calling macros that take arguments, there must not be any white space between the macro name and the open parenthesis.
AC_INIT ([oops], [1.0]) # incorrectAC_INIT([hello], [1.0]) # good
Arguments should be enclosed within the quote characters ‘[’ and ‘]’, and be separated by commas. Any leading blanks or newlines in arguments are ignored, unless they are quoted. You should always quote an argument that might contain a macro name, comma, parenthesis, or a leading blank or newline. This rule applies recursively for every macro call, including macros called from other macros. For more details on quoting rules, see Programming in M4.
For instance:
AC_CHECK_HEADER([stdio.h],[AC_DEFINE([HAVE_STDIO_H], [1],[Define to 1 if you have <stdio.h>.])],[AC_MSG_ERROR([sorry, can't do anything for you])])
is quoted properly. You may safely simplify its quotation to:
AC_CHECK_HEADER([stdio.h],[AC_DEFINE([HAVE_STDIO_H], 1,[Define to 1 if you have <stdio.h>.])],[AC_MSG_ERROR([sorry, can't do anything for you])])
because ‘1’ cannot contain a macro call. Here, the argument of AC_MSG_ERROR
must be quoted; otherwise, its comma would be interpreted as an argument separator. Also, the second and third arguments of ‘AC_CHECK_HEADER’ must be quoted, since they contain macro calls. The three arguments ‘HAVE_STDIO_H’, ‘stdio.h’, and ‘Define to 1 if you have <stdio.h>.’ do not need quoting, but if you unwisely defined a macro with a name like ‘Define’ or ‘stdio’ then they would need quoting. Cautious Autoconf users would keep the quotes, but many Autoconf users find such precautions annoying, and would rewrite the example as follows:
AC_CHECK_HEADER(stdio.h,[AC_DEFINE(HAVE_STDIO_H, 1,[Define to 1 if you have <stdio.h>.])],[AC_MSG_ERROR([sorry, can't do anything for you])])
This is safe, so long as you adopt good naming conventions and do not define macros with names like ‘HAVE_STDIO_H’, ‘stdio’, or ‘h’. Though it is also safe here to omit the quotes around ‘Define to 1 if you have <stdio.h>.’ this is not recommended, as message strings are more likely to inadvertently contain commas.
The following example is wrong and dangerous, as it is underquoted:
AC_CHECK_HEADER(stdio.h,AC_DEFINE(HAVE_STDIO_H, 1,Define to 1 if you have <stdio.h>.),AC_MSG_ERROR([sorry, can't do anything for you]))
In other cases, you may have to use text that also resembles a macro call. You must quote that text even when it is not passed as a macro argument. For example, these two approaches in configure.ac (quoting just the potential problems, or quoting the entire line) will protect your script in case autoconf ever adds a macro AC_DC
:
echo "Hard rock was here! --[AC_DC]"[echo "Hard rock was here! --AC_DC"]
which results in this text in configure:
echo "Hard rock was here! --AC_DC"echo "Hard rock was here! --AC_DC"
When you use the same text in a macro argument, you must therefore have an extra quotation level (since one is stripped away by the macro substitution). In general, then, it is a good idea to use double quoting for all literal string arguments, either around just the problematic portions, or over the entire argument:
AC_MSG_WARN([[AC_DC] stinks --Iron Maiden])AC_MSG_WARN([[AC_DC stinks --Iron Maiden]])
However, the above example triggers a warning about a possibly unexpanded macro when running autoconf, because it collides with the namespace of macros reserved for the Autoconf language. To be really safe, you can use additional escaping (either a quadrigraph, or creative shell constructs) to silence that particular warning:
echo "Hard rock was here! --AC""_DC"AC_MSG_WARN([[AC@&t@_DC stinks --Iron Maiden]])
You are now able to understand one of the constructs of Autoconf that has been continually misunderstood... The rule of thumb is that whenever you expect macro expansion, expect quote expansion; i.e., expect one level of quotes to be lost. For instance:
AC_COMPILE_IFELSE(AC_LANG_SOURCE([char b[10];]), [],[AC_MSG_ERROR([you lose])])
is incorrect: here, the first argument of AC_LANG_SOURCE
is ‘char b[10];’ and is expanded once, which results in ‘char b10;’; and the AC_LANG_SOURCE
is also expanded prior to being passed to AC_COMPILE_IFELSE
. (There was an idiom common in Autoconf's past to address this issue via the M4 changequote
primitive, but do not use it!) Let's take a closer look: the author meant the first argument to be understood as a literal, and therefore it must be quoted twice; likewise, the intermediate AC_LANG_SOURCE
macro should be quoted once so that it is only expanded after the rest of the body of AC_COMPILE_IFELSE
is in place:
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[char b[10];]])], [],[AC_MSG_ERROR([you lose])])
Voilà, you actually produce ‘char b[10];’ this time!
On the other hand, descriptions (e.g., the last parameter of AC_DEFINE
or AS_HELP_STRING
) are not literals—they are subject to line breaking, for example—and should not be double quoted. Even if these descriptions are short and are not actually broken, double quoting them yields weird results.
Some macros take optional arguments, which this documentation represents as [arg] (not to be confused with the quote characters). You may just leave them empty, or use ‘[]’ to make the emptiness of the argument explicit, or you may simply omit the trailing commas. The three lines below are equivalent:
AC_CHECK_HEADERS([stdio.h], [], [], [])AC_CHECK_HEADERS([stdio.h],,,)AC_CHECK_HEADERS([stdio.h])
It is best to put each macro call on its own line in configure.ac. Most of the macros don't add extra newlines; they rely on the newline after the macro call to terminate the commands. This approach makes the generated configure script a little easier to read by not inserting lots of blank lines. It is generally safe to set shell variables on the same line as a macro call, because the shell allows assignments without intervening newlines.
You can include comments in configure.ac files by starting them with the ‘#’. For example, it is helpful to begin configure.ac files with a line like this:
# Process this file with autoconf to produce a configure script.
Previous: Autoconf Language, Up: Writing Autoconf Input
3.1.3 Standard configure.ac Layout
The order in which configure.ac calls the Autoconf macros is not important, with a few exceptions. Every configure.ac must contain a call to AC_INIT
before the checks, and a call to AC_OUTPUT
at the end (see Output). Additionally, some macros rely on other macros having been called first, because they check previously set values of some variables to decide what to do. These macros are noted in the individual descriptions (see Existing Tests), and they also warn you when configure is created if they are called out of order.
To encourage consistency, here is a suggested order for calling the Autoconf macros. Generally speaking, the things near the end of this list are those that could depend on things earlier in it. For example, library functions could be affected by types and libraries.
Autoconf requirementsAC_INIT(
package,
version,
bug-report-address)
information on the packagechecks for programschecks for librarieschecks for header fileschecks for typeschecks for structureschecks for compiler characteristicschecks for library functionschecks for system servicesAC_CONFIG_FILES(
[file...])
AC_OUTPUT
Next: ifnames Invocation, Previous: Writing Autoconf Input, Up: Making configure Scripts
3.2 Using autoscan to Create configure.ac
The autoscan program can help you create and/or maintain a configure.ac file for a software package. autoscan examines source files in the directory tree rooted at a directory given as a command line argument, or the current directory if none is given. It searches the source files for common portability problems and creates a file configure.scan which is a preliminary configure.ac for that package, and checks a possibly existing configure.ac for completeness.
When using autoscan to create a configure.ac, you should manually examine configure.scan before renaming it to configure.ac; it probably needs some adjustments. Occasionally, autoscan outputs a macro in the wrong order relative to another macro, so that autoconf produces a warning; you need to move such macros manually. Also, if you want the package to use a configuration header file, you must add a call to AC_CONFIG_HEADERS
(see Configuration Headers). You might also have to change or add some #if
directives to your program in order to make it work with Autoconf (see ifnames Invocation, for information about a program that can help with that job).
When using autoscan to maintain a configure.ac, simply consider adding its suggestions. The file autoscan.log contains detailed information on why a macro is requested.
autoscan uses several data files (installed along with Autoconf) to determine which macros to output when it finds particular symbols in a package's source files. These data files all have the same format: each line consists of a symbol, one or more blanks, and the Autoconf macro to output if that symbol is encountered. Lines starting with ‘#’ are comments.
autoscan accepts the following options:
--help
-h
Print a summary of the command line options and exit.
--version
-V
Print the version number of Autoconf and exit.
--verbose
-v
Print the names of the files it examines and the potentially interesting symbols it finds in them. This output can be voluminous.
--debug
-d
Don't remove temporary files.
--include=dir
-I dir
Append dir to the include path. Multiple invocations accumulate.
--prepend-include=dir
-B dir
Prepend dir to the include path. Multiple invocations accumulate.
Next: autoconf Invocation, Previous: autoscan Invocation, Up: Making configure Scripts
3.3 Using ifnames to List Conditionals
ifnames can help you write configure.ac for a software package. It prints the identifiers that the package already uses in C preprocessor conditionals. If a package has already been set up to have some portability, ifnames can thus help you figure out what its configure needs to check for. It may help fill in some gaps in a configure.ac generated by autoscan (see autoscan Invocation).
ifnames accepts the following options:
Print a summary of the command line options and exit.
Print the version number of Autoconf and exit.
Next: autoreconf Invocation, Previous: ifnames Invocation, Up: Making configure Scripts
3.4 Using autoconf to Create configure
To create configure from configure.ac, run the autoconf program with no arguments. autoconf processes configure.ac with the M4 macro processor, using the Autoconf macros. If you give autoconf an argument, it reads that file instead of configure.ac and writes the configuration script to the standard output instead of to configure. If you give autoconf the argument -, it reads from the standard input instead of configure.ac and writes the configuration script to the standard output.
The Autoconf macros are defined in several files. Some of the files are distributed with Autoconf; autoconf reads them first. Then it looks for the optional file acsite.m4 in the directory that contains the distributed Autoconf macro files, and for the optional file aclocal.m4 in the current directory. Those files can contain your site's or the package's own Autoconf macro definitions (see Writing Autoconf Macros, for more information). If a macro is defined in more than one of the files that autoconf reads, the last definition it reads overrides the earlier ones.
autoconf accepts the following options:
--help
-h
Print a summary of the command line options and exit.
--version
-V
Print the version number of Autoconf and exit.
--verbose
-v
Report processing steps.
--debug
-d
Don't remove the temporary files.
--force
-f
Remake configure even if newer than its input files.
--include=dir
-I dir
Append dir to the include path. Multiple invocations accumulate.
--prepend-include=dir
-B dir
Prepend dir to the include path. Multiple invocations accumulate.
--output=file
-o file
Save output (script or trace) to file. The file - stands for the standard output.
--warnings=category
-W category
Report the warnings related to category (which can actually be a comma separated list). See Reporting Messages, macro AC_DIAGNOSE
, for a comprehensive list of categories. Special values include:
disable warnings falling into category
$ autoconf -t AC_SUBSTconfigure.ac:2:AC_SUBST:ECHO_Cconfigure.ac:2:AC_SUBST:ECHO_Nconfigure.ac:2:AC_SUBST:ECHO_TMore traces deleted
The example below highlights the difference between ‘$@’, ‘$*’, and ‘$%’.
$ cat configure.acAC_DEFINE(This, is, [an[example]])$ autoconf -t 'AC_DEFINE:@: $@*: $*%: $%'@: [This],[is],[an[example]]*: This,is,an[example]%: This:is:an [example]
The format gives you a lot of freedom:
$ autoconf -t 'AC_SUBST:$$ac_subst{"$1"} = "$f:$l";'$ac_subst{"ECHO_C"} = "configure.ac:2";$ac_subst{"ECHO_N"} = "configure.ac:2";$ac_subst{"ECHO_T"} = "configure.ac:2";More traces deleted
$ autoconf -t 'AM_MISSING_PROG:${|:::::|}*'ACLOCAL|:::::|aclocal|:::::|$missing_dirAUTOCONF|:::::|autoconf|:::::|$missing_dirAUTOMAKE|:::::|automake|:::::|$missing_dirMore traces deleted
Previous: autoconf Invocation, Up: Making configure Scripts
3.5 Using autoreconf to Update configure Scripts
Installing the various components of the GNU Build System can be tedious: running autopoint for Gettext, automake for Makefile.in etc. in each directory. It may be needed either because some tools such as automake have been updated on your system, or because some of the sources such as configure.ac have been updated, or finally, simply in order to install the GNU Build System in a fresh tree.
autoreconf runs autoconf, autoheader, aclocal, automake, libtoolize, and autopoint (when appropriate) repeatedly to update the GNU Build System in the specified directories and their subdirectories (see Subdirectories). By default, it only remakes those files that are older than their sources. The environment variables AUTOM4TE, AUTOCONF, AUTOHEADER, AUTOMAKE, ACLOCAL, AUTOPOINT, LIBTOOLIZE, M4, and MAKE may be used to override the invocation of the respective tools.
If you install a new version of some tool, you can make autoreconf remake all of the files by giving it the --force option.
See Automatic Remaking, for Make rules to automatically rebuild configure scripts when their source files change. That method handles the timestamps of configuration header templates properly, but does not pass --autoconf-dir=dir or --localdir=dir.
autoreconf accepts the following options:
Print a summary of the command line options and exit.
Print the version number of Autoconf and exit.
Don't remove the temporary files.
Do not rebuild files in subdirectories to configure (see Subdirectories, macro AC_CONFIG_SUBDIRS
).
Report the warnings related to category (which can actually be a comma separated list).
‘cross’
related to cross compilation issues.
‘obsolete’
report the uses of obsolete constructs.
‘portability’
portability issues
‘syntax’
dubious syntactic constructs.
‘all’
report all the warnings
‘none’
report none
‘error’
treats warnings as errors
‘no-category’
disable warnings falling into category
Warnings about ‘syntax’ are enabled by default, and the environment variable WARNINGS, a comma separated list of categories, is honored as well. Passing -W category actually behaves as if you had passed --warnings syntax,$WARNINGS,category. To disable the defaults and WARNINGS, and then enable warnings about obsolete constructs, use -W none,obsolete.
If you want autoreconf to pass flags that are not listed here on to aclocal, set ACLOCAL_AMFLAGS
in your Makefile.am. Due to a limitation in the Autoconf implementation these flags currently must be set on a single line in Makefile.am, without any backslash-newlines.
Next: Existing Tests, Previous: Making configure Scripts, Up: Top
4 Initialization and Output Files
Autoconf-generated configure scripts need some information about how to initialize, such as how to find the package's source files and about the output files to produce. The following sections describe the initialization and the creation of output files.
- Initializing configure: Option processing etc.
- Versioning: Dealing with Autoconf versions
- Notices: Copyright, version numbers in configure
- Input: Where Autoconf should find files
- Output: Outputting results from the configuration
- Configuration Actions: Preparing the output based on results
- Configuration Files: Creating output files
- Makefile Substitutions: Using output variables in makefiles
- Configuration Headers: Creating a configuration header file
- Configuration Commands: Running arbitrary instantiation commands
- Configuration Links: Links depending on the configuration
- Subdirectories: Configuring independent packages together
- Default Prefix: Changing the default installation prefix
Next: Versioning, Up: Setup
4.1 Initializing configure
Every configure script must call AC_INIT
before doing anything else that produces output. Calls to silent macros, such as AC_DEFUN
, may also occur prior to AC_INIT
, although these are generally used via aclocal.m4, since that is implicitly included before the start of configure.ac. The only other required macro is AC_OUTPUT
(see Output).
— Macro: AC_INIT (package, version, [bug-report], [tarname], [url])
Process any command-line arguments and perform initialization and verification.
Set the name of the package and its version. These are typically used in --version support, including that of configure. The optional argument bug-report should be the email to which users should send bug reports. The package tarname differs from package: the latter designates the full package name (e.g., ‘GNU Autoconf’), while the former is meant for distribution tar ball names (e.g., ‘autoconf’). It defaults to package with ‘GNU ’ stripped, lower-cased, and all characters other than alphanumerics and underscores are changed to ‘-’. If provided, url should be the home page for the package.
The arguments of
AC_INIT
must be static, i.e., there should not be any shell computation, quotes, or newlines, but they can be computed by M4. This is because the package information strings are expanded at M4 time into several contexts, and must give the same text at shell time whether used in single-quoted strings, double-quoted strings, quoted here-documents, or unquoted here-documents. It is permissible to usem4_esyscmd
orm4_esyscmd_s
for computing a version string that changes with every commit to a version control system (in fact, Autoconf does just that, for all builds of the development tree made between releases).The following M4 macros (e.g.,
AC_PACKAGE_NAME
), output variables (e.g.,PACKAGE_NAME
), and preprocessor symbols (e.g.,PACKAGE_NAME
), are defined byAC_INIT
:
AC_PACKAGE_NAME
,PACKAGE_NAME
Exactly package.
AC_PACKAGE_TARNAME
,PACKAGE_TARNAME
Exactly tarname, possibly generated from package.
AC_PACKAGE_VERSION
,PACKAGE_VERSION
Exactly version.
AC_PACKAGE_STRING
,PACKAGE_STRING
Exactly ‘package version’.
AC_PACKAGE_BUGREPORT
,PACKAGE_BUGREPORT
Exactly bug-report, if one was provided. Typically an email address, or URL to a bug management web page.
AC_PACKAGE_URL
,PACKAGE_URL
Exactly url, if one was provided. If url was empty, but package begins with ‘GNU ’, then this defaults to ‘http://www.gnu.org/software/tarname/’, otherwise, no URL is assumed.
If your configure script does its own option processing, it should inspect ‘$@’ or ‘$*’ immediately after calling AC_INIT
, because other Autoconf macros liberally use the set command to process strings, and this has the side effect of updating ‘$@’ and ‘$*’. However, we suggest that you use standard macros like AC_ARG_ENABLE
instead of attempting to implement your own option processing. See Site Configuration.
Next: Notices, Previous: Initializing configure, Up: Setup
4.2 Dealing with Autoconf versions
AC_PREREQ([2.69])
This macro was introduced in Autoconf 2.62. It identifies the version of Autoconf that is currently parsing the input file, in a format suitable for
m4_version_compare
(see m4_version_compare); in other words, for this release of Autoconf, its value is ‘2.69’. One potential use of this macro is for writing conditional fallbacks based on when a feature was added to Autoconf, rather than usingAC_PREREQ
to require the newer version of Autoconf. However, remember that the Autoconf philosophy favors feature checks over version checks.
Next: Input, Previous: Versioning, Up: Setup
4.3 Notices in configure
The following macros manage version numbers for configure scripts. Using them is optional.
— Macro: AC_COPYRIGHT (copyright-notice)
The copyright-notice shows up in both the head of configure and in ‘configure --version’.
— Macro: AC_REVISION (revision-info)
For example, this line in configure.ac:
AC_REVISION([$Revision: 1.30 $])#!/bin/sh# From configure.ac Revision: 1.30
Next: Output, Previous: Notices, Up: Setup
4.4 Finding configure Input
— Macro: AC_CONFIG_SRCDIR (unique-file-in-source-dir)
unique-file-in-source-dir is some file that is in the package's source directory; configure checks for this file's existence to make sure that the directory that it is told contains the source code in fact does. Occasionally people accidentally specify the wrong directory with --srcdir; this is a safety check. See configure Invocation, for more information.
— Macro: AC_CONFIG_AUX_DIR (dir)
Use the auxiliary build tools (e.g., install-sh, config.sub, config.guess, Cygnus configure, Automake and Libtool scripts, etc.) that are in directory dir. These are auxiliary files used in configuration. dir can be either absolute or relative to srcdir. The default is srcdir or srcdir/.. or srcdir/../.., whichever is the first that contains install-sh. The other files are not checked for, so that using
AC_PROG_INSTALL
does not automatically require distributing the other auxiliary files. It checks for install.sh also, but that name is obsolete because some make have a rule that creates install from it if there is no makefile.The auxiliary directory is commonly named build-aux. If you need portability to DOS variants, do not name the auxiliary directory aux. See File System Conventions.
— Macro: AC_REQUIRE_AUX_FILE (file)
Declares that file is expected in the directory defined above. In Autoconf proper, this macro does nothing: its sole purpose is to be traced by third-party tools to produce a list of expected auxiliary files. For instance it is called by macros like
AC_PROG_INSTALL
(see Particular Programs) orAC_CANONICAL_BUILD
(see Canonicalizing) to register the auxiliary files they need.
— Macro: AC_CONFIG_MACRO_DIR (dir)
Specify dir as the location of additional local Autoconf macros. This macro is intended for use by future versions of commands like autoreconf that trace macro calls. It should be called directly from configure.ac so that tools that install macros for aclocal can find the macros' declarations.
Note that if you use aclocal from Automake to generate aclocal.m4, you must also set
ACLOCAL_AMFLAGS = -I
dir in your top-level Makefile.am. Due to a limitation in the Autoconf implementation of autoreconf, these include directives currently must be set on a single line in Makefile.am, without any backslash-newlines.
Next: Configuration Actions, Previous: Input, Up: Setup
4.5 Outputting Files
Every Autoconf script, e.g., configure.ac, should finish by calling AC_OUTPUT
. That is the macro that generates and runs config.status, which in turn creates the makefiles and any other files resulting from configuration. This is the only required macro besides AC_INIT
(see Input).
— Macro: AC_OUTPUT
Generate config.status and launch it. Call this macro once, at the end of configure.ac.
— Macro: AC_PROG_MAKE_SET
@SET_MAKE@
Next: Configuration Files, Previous: Output, Up: Setup
4.6 Performing Configuration Actions
configure is designed so that it appears to do everything itself, but there is actually a hidden slave: config.status. configure is in charge of examining your system, but it is config.status that actually takes the proper actions based on the results of configure. The most typical task of config.status is to instantiate files.
This section describes the common behavior of the four standard instantiating macros: AC_CONFIG_FILES
, AC_CONFIG_HEADERS
, AC_CONFIG_COMMANDS
and AC_CONFIG_LINKS
. They all have this prototype:
AC_CONFIG_ITEMS(tag..., [commands], [init-cmds])
where the arguments are:
tag...
A blank-or-newline-separated list of tags, which are typically the names of the files to instantiate.
You are encouraged to use literals as tags. In particular, you should avoid
... && my_foos="$my_foos fooo"... && my_foos="$my_foos foooo"AC_CONFIG_ITEMS([$my_foos])
and use this instead:
... && AC_CONFIG_ITEMS([fooo])... && AC_CONFIG_ITEMS([foooo])
The macros AC_CONFIG_FILES
and AC_CONFIG_HEADERS
use special tag values: they may have the form ‘output’ or ‘output:inputs’. The file output is instantiated from its templates, inputs (defaulting to ‘output.in’).
‘AC_CONFIG_FILES([Makefile:boiler/top.mk:boiler/bot.mk])’, for example, asks for the creation of the file Makefile that contains the expansion of the output variables in the concatenation of boiler/top.mk and boiler/bot.mk.
The special value ‘-’ might be used to denote the standard output when used in output, or the standard input when used in the inputs. You most probably don't need to use this in configure.ac, but it is convenient when using the command line interface of ./config.status, see config.status Invocation, for more details.
The inputs may be absolute or relative file names. In the latter case they are first looked for in the build tree, and then in the source tree. Input files should be text files, and a line length below 2000 bytes should be safe.
commands
Shell commands output literally into config.status, and associated with a tag that the user can use to tell config.status which commands to run. The commands are run each time a tag request is given to config.status, typically each time the file tag is created.
The variables set during the execution of configure are not available here: you first need to set them via the init-cmds. Nonetheless the following variables are precomputed:
srcdir
The name of the top source directory, assuming that the working directory is the top build directory. This is what the configure option --srcdir sets.
ac_top_srcdir
The name of the top source directory, assuming that the working directory is the current build directory.
ac_top_build_prefix
The name of the top build directory, assuming that the working directory is the current build directory. It can be empty, or else ends with a slash, so that you may concatenate it.
ac_srcdir
The name of the corresponding source directory, assuming that the working directory is the current build directory.
tmp
The name of a temporary directory within the build tree, which you can use if you need to create additional temporary files. The directory is cleaned up when config.status is done or interrupted. Please use package-specific file name prefixes to avoid clashing with files that config.status may use internally.
The current directory refers to the directory (or pseudo-directory) containing the input part of tags. For instance, running
AC_CONFIG_COMMANDS([deep/dir/out:in/in.in], [...], [...])
with --srcdir=../package produces the following values:
# Argument of --srcdirsrcdir='../package'# Reversing deep/dirac_top_build_prefix='../../'# Concatenation of $ac_top_build_prefix and srcdirac_top_srcdir='../../../package'# Concatenation of $ac_top_srcdir and deep/dirac_srcdir='../../../package/deep/dir'
independently of ‘in/in.in’.
init-cmds
Shell commands output unquoted near the beginning of config.status, and executed each time config.status runs (regardless of the tag). Because they are unquoted, for example, ‘$var’ is output as the value of var
. init-cmds is typically used by configure to give config.status some variables it needs to run the commands.
You should be extremely cautious in your variable names: all the init-cmds share the same name space and may overwrite each other in unpredictable ways. Sorry...
All these macros can be called multiple times, with different tag values, of course!
Next: Makefile Substitutions, Previous: Configuration Actions, Up: Setup
4.7 Creating Configuration Files
Be sure to read the previous section, Configuration Actions.
— Macro: AC_CONFIG_FILES (file..., [cmds], [init-cmds])
Make
AC_OUTPUT
create each file by copying an input file (by default file.in), substituting the output variable values. This macro is one of the instantiating macros; see Configuration Actions. See Makefile Substitutions, for more information on using output variables. See Setting Output Variables, for more information on creating them. This macro creates the directory that the file is in if it doesn't exist. Usually, makefiles are created this way, but other files, such as .gdbinit, can be specified as well.Typical calls to
AC_CONFIG_FILES
look like this:AC_CONFIG_FILES([Makefile src/Makefile man/Makefile X/Imakefile])AC_CONFIG_FILES([autoconf], [chmod +x autoconf])AC_CONFIG_FILES([Makefile:boiler/top.mk:boiler/bot.mk][lib/Makefile:boiler/lib.mk])
Next: Configuration Headers, Previous: Configuration Files, Up: Setup
4.8 Substitutions in Makefiles
See Makefile Conventions, for more information on what to put in makefiles.
- Preset Output Variables: Output variables that are always set
- Installation Directory Variables: Other preset output variables
- Changed Directory Variables: Warnings about datarootdir
- Build Directories: Supporting multiple concurrent compiles
- Automatic Remaking: Makefile rules for configuring
Next: Installation Directory Variables, Up: Makefile Substitutions
4.8.1 Preset Output Variables
Some output variables are preset by the Autoconf macros. Some of the Autoconf macros set additional output variables, which are mentioned in the descriptions for those macros. See Output Variable Index, for a complete list of output variables. See Installation Directory Variables, for the list of the preset ones related to installation directories. Below are listed the other preset ones, many of which are precious variables (see Setting Output Variables, AC_ARG_VAR
).
A comment saying that the file was generated automatically by configure and giving the name of the input file.
AC_OUTPUT
adds a comment line containing this variable to the top of every makefile it creates. For other files, you should reference this variable in a comment at the top of each input file. For example, an input shell script should begin like this:#!/bin/sh# @configure_input@The presence of that line also reminds people editing the file that it needs to be processed by configure in order to be used.
— Variable: CPPFLAGS
See Special Chars in Variables, for limitations that
CPPFLAGS
might run into.
-D options to pass to the C compiler. If
AC_CONFIG_HEADERS
is called, configure replaces ‘@DEFS@’ with -DHAVE_CONFIG_H instead (see Configuration Headers). This variable is not defined while configure is performing its tests, only when creating the output files. See Setting Output Variables, for how to check the results of previous tests.
— Variable: ECHO_C
— Variable: ECHO_N— Variable: ECHO_T
How does one suppress the trailing newline from echo for question-answer message pairs? These variables provide a way:
echo $ECHO_N "And the winner is... $ECHO_C"sleep 100000000000echo "${ECHO_T}dead."Some old and uncommon echo implementations offer no means to achieve this, in which case
ECHO_T
is set to tab. You might not want to use it.
— Variable: ERLCFLAGS
Don't use this variable to pass library names (-l) to the linker; use
LIBS
instead.
Rigorously equal to ‘.’. Added for symmetry only.
— Variable: abs_builddir
Absolute name of
builddir
.
— Variable: top_builddir
The relative name of the top level of the current build tree. In the top-level directory, this is the same as
builddir
.
— Variable: top_build_prefix
The relative name of the top level of the current build tree with final slash if nonempty. This is the same as
top_builddir
, except that it contains zero or more runs of../
, so it should not be appended with a slash for concatenation. This helps for make implementations that otherwise do not treat ./file and file as equal in the toplevel build directory.
— Variable: abs_top_builddir
Absolute name of
top_builddir
.
— Variable: srcdir
The name of the directory that contains the source code for that makefile.
— Variable: abs_srcdir
Absolute name of
srcdir
.
— Variable: top_srcdir
The name of the top-level source code directory for the package. In the top-level directory, this is the same as
srcdir
.
— Variable: abs_top_srcdir
Absolute name of
top_srcdir
.
Next: Changed Directory Variables, Previous: Preset Output Variables, Up: Makefile Substitutions
4.8.2 Installation Directory Variables
The directory for installing executables that users run.
— Variable: datadir
The directory for installing idiosyncratic read-only architecture-independent data.
— Variable: datarootdir
The root of the directory tree for read-only architecture-independent data files.
— Variable: docdir
The directory for installing documentation files (other than Info and man).
— Variable: dvidir
The directory for installing documentation files in DVI format.
— Variable: exec_prefix
The installation prefix for architecture-dependent files. By default it's the same as
prefix
. You should avoid installing anything directly toexec_prefix
. However, the default value for directories containing architecture-dependent files should be relative toexec_prefix
.
— Variable: htmldir
The directory for installing HTML documentation.
— Variable: includedir
The directory for installing C header files.
— Variable: infodir
The directory for installing documentation in Info format.
— Variable: libdir
The directory for installing object code libraries.
— Variable: libexecdir
The directory for installing executables that other programs run.
— Variable: localedir
The directory for installing locale-dependent but architecture-independent data, such as message catalogs. This directory usually has a subdirectory per locale.
— Variable: localstatedir
The directory for installing modifiable single-machine data.
— Variable: mandir
The top-level directory for installing documentation in man format.
— Variable: oldincludedir
The directory for installing C header files for non-GCC compilers.
— Variable: pdfdir
The directory for installing PDF documentation.
— Variable: prefix
The common installation prefix for all files. If
exec_prefix
is defined to a different value,prefix
is used only for architecture-independent files.
— Variable: psdir
The directory for installing PostScript documentation.
— Variable: sbindir
The directory for installing executables that system administrators run.
— Variable: sharedstatedir
The directory for installing modifiable architecture-independent data.
— Variable: sysconfdir
The directory for installing read-only single-machine data.
Most of these variables have values that rely on prefix
or exec_prefix
. It is deliberate that the directory output variables keep them unexpanded: typically ‘@datarootdir@’ is replaced by ‘${prefix}/share’, not ‘/usr/local/share’, and ‘@datadir@’ is replaced by ‘${datarootdir}’.
This behavior is mandated by the GNU Coding Standards, so that when the user runs:
‘make’
she can still specify a different prefix from the one specified to configure, in which case, if needed, the package should hard code dependencies corresponding to the make-specified prefix.
‘make install’
she can specify a different installation location, in which case the package must still depend on the location which was compiled in (i.e., never recompile when ‘make install’ is run). This is an extremely important feature, as many people may decide to install all the files of a package grouped together, and then install links from the final locations to there.
In order to support these features, it is essential that datarootdir
remains defined as ‘${prefix}/share’, so that its value can be expanded based on the current value of prefix
.
A corollary is that you should not use these variables except in makefiles. For instance, instead of trying to evaluate datadir
in configure and hard-coding it in makefiles using e.g., ‘AC_DEFINE_UNQUOTED([DATADIR], ["$datadir"], [Data directory.])’, you should add -DDATADIR='$(datadir)' to your makefile's definition of CPPFLAGS
(AM_CPPFLAGS
if you are also using Automake).
Similarly, you should not rely on AC_CONFIG_FILES
to replace bindir
and friends in your shell scripts and other files; instead, let make manage their replacement. For instance Autoconf ships templates of its shell scripts ending with ‘.in’, and uses a makefile snippet similar to the following to build scripts like autoheader and autom4te:
edit = sed \-e 's|@bindir[@]|$(bindir)|g' \-e 's|@pkgdatadir[@]|$(pkgdatadir)|g' \-e 's|@prefix[@]|$(prefix)|g'autoheader autom4te: Makefilerm -f $@ $@.tmpsrcdir=''; \test -f ./$@.in || srcdir=$(srcdir)/; \$(edit) $${srcdir}$@.in >$@.tmpchmod +x $@.tmpchmod a-w $@.tmpmv $@.tmp $@autoheader: $(srcdir)/autoheader.inautom4te: $(srcdir)/autom4te.in
Some details are noteworthy:
‘@bindir[@]’
The brackets prevent configure from replacing ‘@bindir@’ in the Sed expression itself. Brackets are preferable to a backslash here, since Posix says ‘\@’ is not portable.
‘$(bindir)’
Don't use ‘@bindir@’! Use the matching makefile variable instead.
‘$(pkgdatadir)’
The example takes advantage of the variable ‘$(pkgdatadir)’ provided by Automake; it is equivalent to ‘$(datadir)/$(PACKAGE)’.
‘/’
Don't use ‘/’ in the Sed expressions that replace file names since most likely the variables you use, such as ‘$(bindir)’, contain ‘/’. Use a shell metacharacter instead, such as ‘|’.
special characters
File names, file name components, and the value of VPATH
should not contain shell metacharacters or white space. See Special Chars in Variables.
dependency on Makefile
Since edit
uses values that depend on the configuration specific values (prefix
, etc.) and not only on VERSION
and so forth, the output depends on Makefile, not configure.ac.
‘$@’
The main rule is generic, and uses ‘$@’ extensively to avoid the need for multiple copies of the rule.
Separated dependencies and single suffix rules
You can't use them! The above snippet cannot be (portably) rewritten as:
autoconf autoheader: Makefile.in:rm -f $@ $@.tmp$(edit) $< >$@.tmpchmod +x $@.tmpmv $@.tmp $@
See Single Suffix Rules, for details.
‘$(srcdir)’
Be sure to specify the name of the source directory, otherwise the package won't support separated builds.
For the more specific installation of Erlang libraries, the following variables are defined:
— Variable: ERLANG_INSTALL_LIB_DIR
— Variable: ERLANG_INSTALL_LIB_DIR_library
See Erlang Libraries, for details.
Next: Build Directories, Previous: Installation Directory Variables, Up: Makefile Substitutions
4.8.3 Changed Directory Variables
In Autoconf 2.60, the set of directory variables has changed, and the defaults of some variables have been adjusted (see Installation Directory Variables) to changes in the GNU Coding Standards. Notably, datadir, infodir, and mandir are now expressed in terms of datarootdir. If you are upgrading from an earlier Autoconf version, you may need to adjust your files to ensure that the directory variables are substituted correctly (see Defining Directories), and that a definition of datarootdir is in place. For example, in a Makefile.in, adding
datarootdir = @datarootdir@
is usually sufficient. If you use Automake to create Makefile.in, it will add this for you.
$ cat configure.acAC_INITAC_CONFIG_FILES([Makefile])AC_OUTPUT$ cat Makefile.inprefix = @prefix@datadir = @datadir@$ autoconf$ configureconfigure: creating ./config.statusconfig.status: creating Makefileconfig.status: WARNING:Makefile.in seems to ignore the --datarootdir setting$ cat Makefileprefix = /usr/localdatadir = ${prefix}/share
Usually one can easily change the file to accommodate both older and newer Autoconf releases:
$ cat Makefile.inprefix = @prefix@datarootdir = @datarootdir@datadir = @datadir@$ configureconfigure: creating ./config.statusconfig.status: creating Makefile$ cat Makefileprefix = /usr/localdatarootdir = ${prefix}/sharedatadir = ${datarootdir}
In some cases, however, the checks may not be able to detect that a suitable initialization of datarootdir
is in place, or they may fail to detect that such an initialization is necessary in the output file. If, after auditing your package, there are still spurious configure warnings about datarootdir
, you may add the line
AC_DEFUN([AC_DATAROOTDIR_CHECKED])
to your configure.ac to disable the warnings. This is an exception to the usual rule that you should not define a macro whose name begins with AC_
(see Macro Names).
Next: Automatic Remaking, Previous: Changed Directory Variables, Up: Makefile Substitutions
4.8.4 Build Directories
srcdir = @srcdir@VPATH = @srcdir@
Do not set VPATH
to the value of another variable (see Variables listed in VPATH.
configure substitutes the correct value for srcdir
when it produces Makefile.
time.info: time.texinfo$(MAKEINFO) '$(srcdir)/time.texinfo'
Previous: Build Directories, Up: Makefile Substitutions
待续...
autoconf 英文手册相关推荐
- lua 5.3 英文手册
http://www.lua.org/manual/5.3/manual.html lua 5.3 英文手册 Lua Lua 5.3 Reference Manual by Roberto Ierus ...
- 芯片的英文手册需要全部看吗?
以下文章来源于:公_众_号开源电子网 读取更多技术文章,请扫码关注 芯片的英文手册需要全部看吗? 进入嵌入式行业的人都知道,必定和英文手册打交道的,例如使用一款PHY芯片设置电路,那么首要任务就是查找 ...
- Autoconf 中文手册
Autoconf Autoconf Creating Automatic Configuration Scripts Edition 2.13, for Autoconf version 2.13 D ...
- linux下man手册汉化后,英文man手册被覆盖的解决办法
今晚我按照https://blog.csdn.net/A___LEi/article/details/115739700的步骤对CentOS 7的man进行了汉化,帖主在使用zman后打开中文man手 ...
- 【Aegisub相关】Lua 手册(中文+英文)
为了方便更多用Aegisub做特效字幕,尤其是想深入学习Lua语言去制作高度自定义的特效字幕的朋友们,一定要牢牢抓住手册,因为用Aegisub做的各种ASS特效字幕,不管多么复杂,其用于控制ASS特效 ...
- 使用autoconf完成编译配置
使用过开源C/C++项目的同学们都知道,标准的编译过程已经变成了简单的三部曲:configure/make/make install, 使用起来很方便,不像平时自己写代码,要手写一堆复杂的Makefi ...
- FreeMarker中文帮助手册API文档,基础入门学习文档
FreeMarker中文帮助手册API文档,基础入门学习文档 分类: 编程技术 发布: bywei 浏览: 7 日期: 2011年5月28日 分享到: QQ空间 新浪微博 腾讯微博 人人网 什么是Fr ...
- 大型项目使用Automake/Autoconf完成编译配置
使用过开源C/C++项目的同学们都知道,标准的编译过程已经变成了简单的三部曲:configure/make/make install, 使用起来很方便,不像平时自己写代码,要手写一堆复杂的Makefi ...
- 各种学习资源 文档、手册 (Docker 、springboot 、Guava、git、logback 、Linux 、MQ、vue、Axios)
前些天发现了一个巨牛的人工智能学习网站,通俗易懂,风趣幽默,忍不住分享一下给大家.点击跳转到教程. 1. Docker 中文手册 :https://yeasy.gitbooks.io/docker_p ...
最新文章
- python依赖包exe文件安装问题
- 域服务器广播消息,广播,组播和UNIX域套接字
- oracle 管道通信,oracle管道化表函数
- C++与Java中的static成员总结
- 2022中国私域流量管理研究报告
- 弹簧触摸开关原理图_电梯弹簧抱闸调整
- iPhone 12可能还有4G版,售价香到不行!
- java比较吊的程序代码_java中 compareTo()的程序代码及用法
- 【空间分析-文章学习笔记】1 基于卫星数据反演及空间分析方法对由pm2.5引导的中国男性肺癌的发病率的预测
- python自动答题助手_头脑王者python答题助手
- ESP8266驱动RDA5807实现的FM收音机,可连接WiFi显示B站粉丝数
- 【强化学习】什么是强化学习算法?
- 射极跟随器负载过重引起的失真问题(摘抄)
- python命令行调试_Linux 黑乎乎的命令行下,如何调试 Python?
- HTML实现简单的注册页面
- redis分布式锁的原子保证
- 新版2022高仿QQ,利用Java swing1:1模仿qq编写的聊天程序
- tomcat 7.0
- 2020年厦门市技能大赛-网络搭建与应用竞赛-正式赛卷(一)技能要求(附脚本配置)
- Deepin linux安装五笔输入法
热门文章
- linux强制执行当前命令,Linux | 常用命令(一)
- 【Tools】推荐一些文件转换转换工具
- 如何增加网站权重?有效提高网站权重的技巧方法
- 提升网站权重有哪些方法?哪些因素会降低网站权重
- Altium Designer快速绘制原理图的一些操作
- pc控制iphone的软件_iPhone Share?这里有一款在 PC 端控制 iPhone 的工具
- 总是空驶、排队等货怎么办?货运要想网络化,运力画像看一看!
- html+css 实现爱心砰砰砰的网页特效
- 【计算机毕业设计】003图书个性化推荐系统的设计与实现
- 解决 SpringBoot 没有主清单属性