mirror of
git://git.sv.gnu.org/autoconf
synced 2025-01-18 10:45:15 +08:00
revise questions
This commit is contained in:
David MacKenzie
parent
3c16e51820
commit
d42634442c
103
autoconf.texi
103
autoconf.texi
@ -3884,9 +3884,9 @@ Here is how to use the variable @code{program_transform_name} in a
|
||||
@file{Makefile.in}:
|
||||
|
||||
@example
|
||||
tn=@@program_transform_name@@
|
||||
transform=@@program_transform_name@@
|
||||
install: all
|
||||
$(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(tn)'`
|
||||
$(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(transform)'`
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
@ -3896,7 +3896,7 @@ If you have more than one program to install, you can do it in a loop:
|
||||
PROGRAMS=cat ls rm
|
||||
install:
|
||||
for p in $(PROGRAMS); do \
|
||||
$(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(tn)'`; \
|
||||
$(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(transform)'`; \
|
||||
done
|
||||
@end example
|
||||
|
||||
@ -4086,7 +4086,7 @@ are addressed.
|
||||
|
||||
@display
|
||||
What are the restrictions on distributing @code{configure}
|
||||
scripts that Autoconf generated? How does that affect my
|
||||
scripts that Autoconf generates? How does that affect my
|
||||
programs that use them?
|
||||
@end display
|
||||
|
||||
@ -4129,10 +4129,10 @@ __line__
|
||||
@end example
|
||||
|
||||
Since only software maintainers need to use Autoconf, and since GNU
|
||||
@code{m4} is simple to configure and install, it does not seem like an
|
||||
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.
|
||||
@code{m4} is simple to configure and install, it seems reasonable to
|
||||
require GNU @code{m4} to be installed also. Many maintainers of GNU and
|
||||
other free software already have most of the GNU utilities installed,
|
||||
since they prefer them.
|
||||
|
||||
@node Bootstrapping, Why Not Imake, Why GNU m4, Questions
|
||||
@section How Can I Bootstrap?
|
||||
@ -4143,56 +4143,52 @@ Autoconf @code{configure} script, how do I bootstrap? It seems
|
||||
like a chicken and egg problem!
|
||||
@end display
|
||||
|
||||
Although GNU @code{m4} does come with a @code{configure} script produced
|
||||
by Autoconf, Autoconf is @emph{not} required in order to run the script
|
||||
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).
|
||||
This is a misunderstanding. Although GNU @code{m4} does come with a
|
||||
@code{configure} script produced by Autoconf, Autoconf is not required
|
||||
in order to run the script and install GNU @code{m4}. Autoconf is only
|
||||
required if you want to change the @code{m4} @code{configure} script,
|
||||
which few people have to do (mainly its maintainer).
|
||||
|
||||
@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.
|
||||
Why not use Imake, instead of @code{configure} scripts?
|
||||
@end display
|
||||
|
||||
The following answer is adapted from one written by Richard Pixley:
|
||||
Several people have written addressing this question, so I will include
|
||||
adaptations of their explanations here.
|
||||
|
||||
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
|
||||
The following answer is based on one written by Richard Pixley:
|
||||
|
||||
Autoconf generated scripts frequently work on machines which it has
|
||||
never 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
|
||||
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 is special-purpose. It is directed 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 the
|
||||
problems are similar. But the GNU tools are 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.
|
||||
Imake templates are a form of standardization. The GNU coding standards
|
||||
address the same issues without necessarily imposing the same
|
||||
restrictions.
|
||||
|
||||
And here is some further explanation, written by Per Bothner:
|
||||
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,
|
||||
@ -4203,6 +4199,31 @@ 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.
|
||||
|
||||
Paul Eggert elaborates more:
|
||||
|
||||
With Autoconf, installers need not assume that Imake itself is already
|
||||
installed and working well. This may not seem like much of an advantage
|
||||
to people who are accustomed to Imake. But on many hosts Imake is not
|
||||
installed or the default installation is not working well, and requiring
|
||||
Imake to install a package hinders the acceptance of that package on
|
||||
those hosts. For example, the Imake template and configuration files
|
||||
might not be installed properly on a host, or the Imake build procedure
|
||||
might wrongly assume that all source files are in one big directory
|
||||
tree, or the Imake configuration might assume one compiler whereas the
|
||||
package or the installer needs to use another, or there might be a
|
||||
version mismatch between the Imake expected by the package and the Imake
|
||||
suported by the host. These problems are much rarer with Autoconf,
|
||||
where each package comes with its own independent configuration
|
||||
processor.
|
||||
|
||||
Also, Imake often suffers from unexpected interactions between
|
||||
@code{make} and the installer's C preprocessor. The fundamental problem
|
||||
here is that the C preprocessor was designed to preprocess C programs,
|
||||
not @file{Makefile}s. This is much less of a problem with Autoconf,
|
||||
which uses the general-purpose preprocessor @code{m4}, and where the
|
||||
package's author (rather than the installer) does the preprocessing in a
|
||||
standard way.
|
||||
|
||||
@node Upgrading, History, Questions, Top
|
||||
@chapter Upgrading From Version 1
|
||||
|
||||
@ -4545,7 +4566,7 @@ Franc,ois
|
||||
Fran\c cois
|
||||
@end tex
|
||||
Pinard, who came up with the idea of making an @file{autoconf} shell
|
||||
script to run @code{m4} and check for unresolved macro calls; Rich
|
||||
script to run @code{m4} and check for unresolved macro calls; Richard
|
||||
Pixley, who suggested running the compiler instead of searching the file
|
||||
system to find include files and symbols, for more accurate results;
|
||||
Karl Berry, who got Autoconf to configure @TeX{} and added the
|
||||
@ -4886,7 +4907,3 @@ easier to use, the macros are listed without their preceding @samp{AC_}.
|
||||
|
||||
@contents
|
||||
@bye
|
||||
|
||||
@c Local variables:
|
||||
@c compile-command: "makeinfo autoconf.texi"
|
||||
@c End:
|
||||
|
||||
@ -3884,9 +3884,9 @@ Here is how to use the variable @code{program_transform_name} in a
|
||||
@file{Makefile.in}:
|
||||
|
||||
@example
|
||||
tn=@@program_transform_name@@
|
||||
transform=@@program_transform_name@@
|
||||
install: all
|
||||
$(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(tn)'`
|
||||
$(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(transform)'`
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
@ -3896,7 +3896,7 @@ If you have more than one program to install, you can do it in a loop:
|
||||
PROGRAMS=cat ls rm
|
||||
install:
|
||||
for p in $(PROGRAMS); do \
|
||||
$(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(tn)'`; \
|
||||
$(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(transform)'`; \
|
||||
done
|
||||
@end example
|
||||
|
||||
@ -4086,7 +4086,7 @@ are addressed.
|
||||
|
||||
@display
|
||||
What are the restrictions on distributing @code{configure}
|
||||
scripts that Autoconf generated? How does that affect my
|
||||
scripts that Autoconf generates? How does that affect my
|
||||
programs that use them?
|
||||
@end display
|
||||
|
||||
@ -4129,10 +4129,10 @@ __line__
|
||||
@end example
|
||||
|
||||
Since only software maintainers need to use Autoconf, and since GNU
|
||||
@code{m4} is simple to configure and install, it does not seem like an
|
||||
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.
|
||||
@code{m4} is simple to configure and install, it seems reasonable to
|
||||
require GNU @code{m4} to be installed also. Many maintainers of GNU and
|
||||
other free software already have most of the GNU utilities installed,
|
||||
since they prefer them.
|
||||
|
||||
@node Bootstrapping, Why Not Imake, Why GNU m4, Questions
|
||||
@section How Can I Bootstrap?
|
||||
@ -4143,56 +4143,52 @@ Autoconf @code{configure} script, how do I bootstrap? It seems
|
||||
like a chicken and egg problem!
|
||||
@end display
|
||||
|
||||
Although GNU @code{m4} does come with a @code{configure} script produced
|
||||
by Autoconf, Autoconf is @emph{not} required in order to run the script
|
||||
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).
|
||||
This is a misunderstanding. Although GNU @code{m4} does come with a
|
||||
@code{configure} script produced by Autoconf, Autoconf is not required
|
||||
in order to run the script and install GNU @code{m4}. Autoconf is only
|
||||
required if you want to change the @code{m4} @code{configure} script,
|
||||
which few people have to do (mainly its maintainer).
|
||||
|
||||
@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.
|
||||
Why not use Imake, instead of @code{configure} scripts?
|
||||
@end display
|
||||
|
||||
The following answer is adapted from one written by Richard Pixley:
|
||||
Several people have written addressing this question, so I will include
|
||||
adaptations of their explanations here.
|
||||
|
||||
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
|
||||
The following answer is based on one written by Richard Pixley:
|
||||
|
||||
Autoconf generated scripts frequently work on machines which it has
|
||||
never 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
|
||||
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 is special-purpose. It is directed 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 the
|
||||
problems are similar. But the GNU tools are 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.
|
||||
Imake templates are a form of standardization. The GNU coding standards
|
||||
address the same issues without necessarily imposing the same
|
||||
restrictions.
|
||||
|
||||
And here is some further explanation, written by Per Bothner:
|
||||
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,
|
||||
@ -4203,6 +4199,31 @@ 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.
|
||||
|
||||
Paul Eggert elaborates more:
|
||||
|
||||
With Autoconf, installers need not assume that Imake itself is already
|
||||
installed and working well. This may not seem like much of an advantage
|
||||
to people who are accustomed to Imake. But on many hosts Imake is not
|
||||
installed or the default installation is not working well, and requiring
|
||||
Imake to install a package hinders the acceptance of that package on
|
||||
those hosts. For example, the Imake template and configuration files
|
||||
might not be installed properly on a host, or the Imake build procedure
|
||||
might wrongly assume that all source files are in one big directory
|
||||
tree, or the Imake configuration might assume one compiler whereas the
|
||||
package or the installer needs to use another, or there might be a
|
||||
version mismatch between the Imake expected by the package and the Imake
|
||||
suported by the host. These problems are much rarer with Autoconf,
|
||||
where each package comes with its own independent configuration
|
||||
processor.
|
||||
|
||||
Also, Imake often suffers from unexpected interactions between
|
||||
@code{make} and the installer's C preprocessor. The fundamental problem
|
||||
here is that the C preprocessor was designed to preprocess C programs,
|
||||
not @file{Makefile}s. This is much less of a problem with Autoconf,
|
||||
which uses the general-purpose preprocessor @code{m4}, and where the
|
||||
package's author (rather than the installer) does the preprocessing in a
|
||||
standard way.
|
||||
|
||||
@node Upgrading, History, Questions, Top
|
||||
@chapter Upgrading From Version 1
|
||||
|
||||
@ -4545,7 +4566,7 @@ Franc,ois
|
||||
Fran\c cois
|
||||
@end tex
|
||||
Pinard, who came up with the idea of making an @file{autoconf} shell
|
||||
script to run @code{m4} and check for unresolved macro calls; Rich
|
||||
script to run @code{m4} and check for unresolved macro calls; Richard
|
||||
Pixley, who suggested running the compiler instead of searching the file
|
||||
system to find include files and symbols, for more accurate results;
|
||||
Karl Berry, who got Autoconf to configure @TeX{} and added the
|
||||
@ -4886,7 +4907,3 @@ easier to use, the macros are listed without their preceding @samp{AC_}.
|
||||
|
||||
@contents
|
||||
@bye
|
||||
|
||||
@c Local variables:
|
||||
@c compile-command: "makeinfo autoconf.texi"
|
||||
@c End:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user