@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
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
@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
@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?
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,
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
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
@contents
@bye
-
-@c Local variables:
-@c compile-command: "makeinfo autoconf.texi"
-@c End:
@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
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
@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
@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?
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,
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
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
@contents
@bye
-
-@c Local variables:
-@c compile-command: "makeinfo autoconf.texi"
-@c End:
projects / thirdparty / autoconf.git / commitdiff
