mirror of
git://git.sv.gnu.org/autoconf
synced 2025-01-18 10:45:15 +08:00
minor tweaks
This commit is contained in:
parent
95571a4492
commit
bf85b76df9
4
NEWS
4
NEWS
@ -10,6 +10,10 @@ Library, need major changes because they relied on undocumented
|
||||
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:
|
||||
|
4
TODO
4
TODO
@ -31,6 +31,10 @@ Things it might be nice to do someday:
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
* 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
|
||||
|
@ -156,6 +156,7 @@ Directory and file names:
|
||||
--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]
|
||||
@ -1140,7 +1141,7 @@ undefine([AC_VAR_NAME])dnl
|
||||
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])
|
||||
|
@ -109,7 +109,7 @@ package. This is edition @value{EDITION}, for Autoconf version @value{VERSION}.
|
||||
* 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.
|
||||
@ -245,11 +245,12 @@ Running @code{configure} Scripts
|
||||
* 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
|
||||
|
||||
@ -332,7 +333,7 @@ Using version 1.3 or later will be much faster than 1.1 or 1.2.
|
||||
|
||||
@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
|
||||
@ -1518,7 +1519,7 @@ set the prefix to @file{/usr/local/gnu}.
|
||||
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
|
||||
@ -3983,7 +3984,7 @@ file in the package.
|
||||
|
||||
@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}
|
||||
@ -4067,19 +4068,20 @@ Makefile: Makefile.in 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
|
||||
@ -4106,7 +4108,7 @@ are. We still encourage software authors to distribute their work under
|
||||
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
|
||||
@ -4132,7 +4134,7 @@ unreasonable burden to require GNU @code{m4} to be installed also. Most
|
||||
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
|
||||
@ -4147,7 +4149,61 @@ and install GNU @code{m4}. Autoconf is only required if you want to
|
||||
@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.
|
||||
|
@ -109,7 +109,7 @@ package. This is edition @value{EDITION}, for Autoconf version @value{VERSION}.
|
||||
* 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.
|
||||
@ -245,11 +245,12 @@ Running @code{configure} Scripts
|
||||
* 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
|
||||
|
||||
@ -332,7 +333,7 @@ Using version 1.3 or later will be much faster than 1.1 or 1.2.
|
||||
|
||||
@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
|
||||
@ -1518,7 +1519,7 @@ set the prefix to @file{/usr/local/gnu}.
|
||||
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
|
||||
@ -3983,7 +3984,7 @@ file in the package.
|
||||
|
||||
@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}
|
||||
@ -4067,19 +4068,20 @@ Makefile: Makefile.in 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
|
||||
@ -4106,7 +4108,7 @@ are. We still encourage software authors to distribute their work under
|
||||
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
|
||||
@ -4132,7 +4134,7 @@ unreasonable burden to require GNU @code{m4} to be installed also. Most
|
||||
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
|
||||
@ -4147,7 +4149,61 @@ and install GNU @code{m4}. Autoconf is only required if you want to
|
||||
@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.
|
||||
|
@ -156,6 +156,7 @@ Directory and file names:
|
||||
--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]
|
||||
@ -1140,7 +1141,7 @@ undefine([AC_VAR_NAME])dnl
|
||||
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])
|
||||
|
Loading…
Reference in New Issue
Block a user