internals of version 1. Future releases of those packages will have
updated configure.in files.
+It's best to use GNU m4 1.3 (or later) with Autoconf version 2.
+Autoconf now makes heavy use of m4 diversions, which were implemented
+inefficiently in GNU m4 releases before 1.3.
+
Major changes in release 2.0:
** New macros:
------------------------------------------------------------------------------
+* Make autoconf diagnose giving too few or too many arguments to macros.
+
+------------------------------------------------------------------------------
+
* Split up AC_SUBST substitutions using a loop to accomodate shells
with severely limited here document sizes, if it turns out to be a problem.
I'm not sure whether the limit is on lines or bytes; if bytes, it
--srcdir=DIR find the sources in DIR [configure dir or ..]
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
+ --program-transform-name=PROGRAM run sed PROGRAM on installed program names
Host type:
--build=BUILD configure for building on BUILD [BUILD=HOST]
--host=HOST configure for HOST [guessed]
dnl ### Checking for libraries
-dnl AC_CHECK_LIB(LIBRARY, FUNCTION, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
+dnl AC_CHECK_LIB(LIBRARY, FUNCTION [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
dnl [, OTHER-LIBRARIES]]])
AC_DEFUN(AC_CHECK_LIB,
[AC_MSG_CHECKING([for -l$1])
* Site Configuration:: Local defaults for @code{configure}.
* Invoking configure:: How to use the Autoconf output.
* Invoking config.status:: Recreating a configuration.
-* Concerns:: Concerns about Autoconf, with answers.
+* Questions:: Questions about Autoconf, with answers.
* Upgrading:: Tips for upgrading from version 1.
* History:: History of Autoconf.
* Old Macro Names:: Backward compatibility macros.
* System Type:: Specifying the system type.
* Optional Features:: Selecting optional features.
-Concerns About Autoconf
+Questions About Autoconf
* Copyright:: Legal restrictions on Autoconf output.
* Why GNU m4:: Why not use the standard @code{m4}?
* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Why Not Imake:: Why GNU uses @code{configure} instead of Imake.
Upgrading From Version 1
@xref{Upgrading}, for information about upgrading from version 1.
@xref{History}, for the story of Autoconf's development.
-@xref{Concerns}, for answers to some common questions about Autoconf.
+@xref{Questions}, for answers to some common questions about Autoconf.
Mail suggestions and bug reports for Autoconf to
@code{bug-gnu-utils@@prep.ai.mit.edu}. Please include the Autoconf version
The following macros check for the presence of certain C library archive
files.
-@defmac AC_CHECK_LIB (@var{library}, @var{function}, @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
+@defmac AC_CHECK_LIB (@var{library}, @var{function} @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
@maindex CHECK_LIB
See whether a test C program can be linked with the library
@var{library}. @var{function} should be the name of a function that the
@include install.texi
-@node Invoking config.status, Concerns, Invoking configure, Top
+@node Invoking config.status, Questions, Invoking configure, Top
@chapter Recreating a Configuration
The @code{configure} script creates a file named @file{config.status}
(If @file{configure.in} does not call @code{AC_CONFIG_HEADER}, there is
no need to set @code{CONFIG_HEADERS} in the @code{make} rules.)
-@node Concerns, Upgrading, Invoking config.status, Top
-@chapter Concerns About Autoconf
+@node Questions, Upgrading, Invoking config.status, Top
+@chapter Questions About Autoconf
-Several concerns about Autoconf come up occasionally. Here some of them
+Several questions about Autoconf come up occasionally. Here some of them
are addressed.
@menu
* Copyright:: Legal restrictions on Autoconf output.
* Why GNU m4:: Why not use the standard @code{m4}?
* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Why Not Imake:: Why GNU uses @code{configure} instead of Imake.
@end menu
-@node Copyright, Why GNU m4, , Concerns
+@node Copyright, Why GNU m4, , Questions
@section Copyright on @code{configure} Scripts
@display
terms like those of the GPL, but doing so is not required to use
Autoconf.
-@node Why GNU m4, Bootstrapping, Copyright, Concerns
+@node Why GNU m4, Bootstrapping, Copyright, Questions
@section Why Require GNU @code{m4}?
@display
maintainers of GNU and other free software already have most of the GNU
utilities installed, since they prefer them.
-@node Bootstrapping, , Why GNU m4, Concerns
+@node Bootstrapping, Why Not Imake, Why GNU m4, Questions
@section How Can I Bootstrap?
@display
@emph{change} the @code{m4} @code{configure} script, which few people
have to do (mainly its maintainer).
-@node Upgrading, History, Concerns, Top
+@node Why Not Imake, , Bootstrapping, Questions
+@section Why Not Imake?
+
+@display
+Why not use Imake, instead of @code{configure} scripts? X
+software which is properly written and which has a properly
+written @file{Imakefile} is almost painless to compile and
+install; and writing @file{Imakefile}s is much much easier than
+writing @file{Makefile}s.
+@end display
+
+The following answer is adapted from one written by Richard Pixley:
+
+Properly written anything should always work. Properly written
+@file{Makefile.in}s and @code{configure} scripts also work. In fact,
+Autoconf generated scripts frequently work on machines which it has not
+ever been set up to handle before. That is, it does a good job of
+inferring a configuration for a new system. Imake cannot do this.
+
+Imake uses a common database of host specific data. For X11, this makes
+sense because the distribution is made as a collection of tools, by one
+central authority who has control over the database.
+
+GNU tools are not released this way. Each GNU tool has a maintainer.
+These maintainers are scattered across the world. Using a common
+database would be a maintenance nightmare. Autoconf may appear to be
+this kind of database, but in fact it is not. Instead of listing host
+dependencies, it lists program requirements.
+
+Imake is very special purpose. It is directed solely at building
+the X11 distribution. By comparison to the GNU tools, this is a
+simple problem. If you view the GNU suite as a collection of native
+tools, then yes, the problems are similar. But the GNU tools are
+much more powerful than that. The development tools can be
+configured as cross tools in almost any host+target permutation.
+All of these configurations can be installed concurrently. They can
+even be configured to share host independent files across hosts.
+Imake doesn't address these issues.
+
+Imake templates are a form of standardization. In the GNU world, the
+GNU coding standards address the same issues without necessarily
+imposing the same restrictions.
+
+And here is some further explanation, written by Per Bothner:
+
+One of the advantages of Imake is that it easy to generate large
+Makefiles using cpp's @samp{#include} and macro mechanisms. However,
+cpp is not programmable: it has limited conditional facilities, and no
+looping. And cpp cannot inspect its environment.
+
+All of these problems are solved by using @file{/bin/sh} instead of cpp.
+The shell is fully programmable, has macro substitution, can execute (or
+source) other shell scripts, and can inspect its environment.
+
+@node Upgrading, History, Questions, Top
@chapter Upgrading From Version 1
Autoconf version 2 is mostly backward compatible with version 1.
* Site Configuration:: Local defaults for @code{configure}.
* Invoking configure:: How to use the Autoconf output.
* Invoking config.status:: Recreating a configuration.
-* Concerns:: Concerns about Autoconf, with answers.
+* Questions:: Questions about Autoconf, with answers.
* Upgrading:: Tips for upgrading from version 1.
* History:: History of Autoconf.
* Old Macro Names:: Backward compatibility macros.
* System Type:: Specifying the system type.
* Optional Features:: Selecting optional features.
-Concerns About Autoconf
+Questions About Autoconf
* Copyright:: Legal restrictions on Autoconf output.
* Why GNU m4:: Why not use the standard @code{m4}?
* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Why Not Imake:: Why GNU uses @code{configure} instead of Imake.
Upgrading From Version 1
@xref{Upgrading}, for information about upgrading from version 1.
@xref{History}, for the story of Autoconf's development.
-@xref{Concerns}, for answers to some common questions about Autoconf.
+@xref{Questions}, for answers to some common questions about Autoconf.
Mail suggestions and bug reports for Autoconf to
@code{bug-gnu-utils@@prep.ai.mit.edu}. Please include the Autoconf version
The following macros check for the presence of certain C library archive
files.
-@defmac AC_CHECK_LIB (@var{library}, @var{function}, @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
+@defmac AC_CHECK_LIB (@var{library}, @var{function} @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
@maindex CHECK_LIB
See whether a test C program can be linked with the library
@var{library}. @var{function} should be the name of a function that the
@include install.texi
-@node Invoking config.status, Concerns, Invoking configure, Top
+@node Invoking config.status, Questions, Invoking configure, Top
@chapter Recreating a Configuration
The @code{configure} script creates a file named @file{config.status}
(If @file{configure.in} does not call @code{AC_CONFIG_HEADER}, there is
no need to set @code{CONFIG_HEADERS} in the @code{make} rules.)
-@node Concerns, Upgrading, Invoking config.status, Top
-@chapter Concerns About Autoconf
+@node Questions, Upgrading, Invoking config.status, Top
+@chapter Questions About Autoconf
-Several concerns about Autoconf come up occasionally. Here some of them
+Several questions about Autoconf come up occasionally. Here some of them
are addressed.
@menu
* Copyright:: Legal restrictions on Autoconf output.
* Why GNU m4:: Why not use the standard @code{m4}?
* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Why Not Imake:: Why GNU uses @code{configure} instead of Imake.
@end menu
-@node Copyright, Why GNU m4, , Concerns
+@node Copyright, Why GNU m4, , Questions
@section Copyright on @code{configure} Scripts
@display
terms like those of the GPL, but doing so is not required to use
Autoconf.
-@node Why GNU m4, Bootstrapping, Copyright, Concerns
+@node Why GNU m4, Bootstrapping, Copyright, Questions
@section Why Require GNU @code{m4}?
@display
maintainers of GNU and other free software already have most of the GNU
utilities installed, since they prefer them.
-@node Bootstrapping, , Why GNU m4, Concerns
+@node Bootstrapping, Why Not Imake, Why GNU m4, Questions
@section How Can I Bootstrap?
@display
@emph{change} the @code{m4} @code{configure} script, which few people
have to do (mainly its maintainer).
-@node Upgrading, History, Concerns, Top
+@node Why Not Imake, , Bootstrapping, Questions
+@section Why Not Imake?
+
+@display
+Why not use Imake, instead of @code{configure} scripts? X
+software which is properly written and which has a properly
+written @file{Imakefile} is almost painless to compile and
+install; and writing @file{Imakefile}s is much much easier than
+writing @file{Makefile}s.
+@end display
+
+The following answer is adapted from one written by Richard Pixley:
+
+Properly written anything should always work. Properly written
+@file{Makefile.in}s and @code{configure} scripts also work. In fact,
+Autoconf generated scripts frequently work on machines which it has not
+ever been set up to handle before. That is, it does a good job of
+inferring a configuration for a new system. Imake cannot do this.
+
+Imake uses a common database of host specific data. For X11, this makes
+sense because the distribution is made as a collection of tools, by one
+central authority who has control over the database.
+
+GNU tools are not released this way. Each GNU tool has a maintainer.
+These maintainers are scattered across the world. Using a common
+database would be a maintenance nightmare. Autoconf may appear to be
+this kind of database, but in fact it is not. Instead of listing host
+dependencies, it lists program requirements.
+
+Imake is very special purpose. It is directed solely at building
+the X11 distribution. By comparison to the GNU tools, this is a
+simple problem. If you view the GNU suite as a collection of native
+tools, then yes, the problems are similar. But the GNU tools are
+much more powerful than that. The development tools can be
+configured as cross tools in almost any host+target permutation.
+All of these configurations can be installed concurrently. They can
+even be configured to share host independent files across hosts.
+Imake doesn't address these issues.
+
+Imake templates are a form of standardization. In the GNU world, the
+GNU coding standards address the same issues without necessarily
+imposing the same restrictions.
+
+And here is some further explanation, written by Per Bothner:
+
+One of the advantages of Imake is that it easy to generate large
+Makefiles using cpp's @samp{#include} and macro mechanisms. However,
+cpp is not programmable: it has limited conditional facilities, and no
+looping. And cpp cannot inspect its environment.
+
+All of these problems are solved by using @file{/bin/sh} instead of cpp.
+The shell is fully programmable, has macro substitution, can execute (or
+source) other shell scripts, and can inspect its environment.
+
+@node Upgrading, History, Questions, Top
@chapter Upgrading From Version 1
Autoconf version 2 is mostly backward compatible with version 1.
--srcdir=DIR find the sources in DIR [configure dir or ..]
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
+ --program-transform-name=PROGRAM run sed PROGRAM on installed program names
Host type:
--build=BUILD configure for building on BUILD [BUILD=HOST]
--host=HOST configure for HOST [guessed]
dnl ### Checking for libraries
-dnl AC_CHECK_LIB(LIBRARY, FUNCTION, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
+dnl AC_CHECK_LIB(LIBRARY, FUNCTION [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
dnl [, OTHER-LIBRARIES]]])
AC_DEFUN(AC_CHECK_LIB,
[AC_MSG_CHECKING([for -l$1])
projects / thirdparty / autoconf.git / commitdiff
