minor tweaks

This commit is contained in:
David MacKenzie 1994-09-16 15:40:36 +00:00
parent 95571a4492
commit bf85b76df9
6 changed files with 148 additions and 26 deletions

4
NEWS
View File

@ -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
View File

@ -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

View File

@ -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])

View File

@ -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.

View File

@ -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.

View File

@ -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])