summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlexandre Duret-Lutz <adl@gnu.org>2004-09-15 20:38:33 +0000
committerAlexandre Duret-Lutz <adl@gnu.org>2004-09-15 20:38:33 +0000
commit9644b61d1f349551238efd9aea22024ad2d78e96 (patch)
tree3dcd295abdc19ff39413e6138124ac72579e07ef
parentb031d32189191212497329ca9620d11bcb01d4f5 (diff)
downloadautomake-9644b61d1f349551238efd9aea22024ad2d78e96.tar.gz
* doc/automake.texi (Dependencies): Link to Dependency Tracking
Evolution. (Dependency Tracking Evolution): Link to GNU make, Sources (for BUILT_SOURCES), and update the paragraph about the "plan" to inline dependency tracking with gcc3.
-rw-r--r--ChangeLog6
-rw-r--r--doc/automake.texi75
2 files changed, 44 insertions, 37 deletions
diff --git a/ChangeLog b/ChangeLog
index 3073f61bb..417ddf7f3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2004-09-15 Alexandre Duret-Lutz <adl@gnu.org>
+ * doc/automake.texi (Dependencies): Link to Dependency Tracking
+ Evolution.
+ (Dependency Tracking Evolution): Link to GNU make, Sources (for
+ BUILT_SOURCES), and update the paragraph about the "plan" to
+ inline dependency tracking with gcc3.
+
* doc/automake.texi (History): New node.
(Dependency Tracking Evolution): New node, filled with a Texinfo
version of Tom Tromey's ``Dependency Tracking in Automake''
diff --git a/doc/automake.texi b/doc/automake.texi
index 0aeba9840..fed94e7a1 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -4337,12 +4337,11 @@ your build.
@cindex depcomp
-Experience with earlier versions of Automake @footnote{See
-@uref{http://sources.redhat.com/automake/dependencies.html} for more
-information on the history and experiences with automatic dependency
-tracking in Automake} taught us that it is not reliable to generate
-dependencies only on the maintainer's system, as configurations vary too
-much. So instead Automake implements dependency tracking at build time.
+Experience with earlier versions of Automake (@pxref{Dependency
+Tracking Evolution}) taught us that it is not reliable to generate
+dependencies only on the maintainer's system, as configurations vary
+too much. So instead Automake implements dependency tracking at build
+time.
Automatic dependency tracking can be suppressed by putting
@code{no-dependencies} in the variable @code{AUTOMAKE_OPTIONS}, or
@@ -7886,7 +7885,9 @@ for dependency tracking work in Automake.
@unnumberedsubsubsec Description
Our first attempt at automatic dependency tracking was based on the
-method recommended by GNU @command{make}.
+method recommended by GNU @command{make}. (@pxref{Automatic
+Prerequisites, , Generating Prerequisites Automatically, make, The GNU
+make Manual})
This version worked by precomputing dependencies ahead of time. For
each source file, it had a special @file{.P} file which held the
@@ -8011,11 +8012,11 @@ form of include directive. Also, we wrote a wrapper script which let
us abstract away differences between dependency tracking methods for
compilers. For instance, some compilers cannot generate dependencies
as a side effect of compilation. In this case we simply have the
-script run the compiler twice. Currently our wrapper script knows
-about twelve different compilers (including a "compiler" which simply
-invokes @command{makedepend} and then the real compiler, which is
-assumed to be a standard Unix-like C compiler with no way to do
-dependency tracking).
+script run the compiler twice. Currently our wrapper script
+(@command{depcomp}) knows about twelve different compilers (including
+a "compiler" which simply invokes @command{makedepend} and then the
+real compiler, which is assumed to be a standard Unix-like C compiler
+with no way to do dependency tracking).
@unnumberedsubsubsec Bugs
@@ -8061,16 +8062,33 @@ have not yet been built.
This was also a problem in the previous dependency tracking implementation.
-The current fix is to use @code{BUILT_SOURCES} to list built
-headers. This causes them to be built before any other other build
-rules are run. This is unsatisfactory as a general solution, however
-in practice it seems sufficient for most actual programs.
+The current fix is to use @code{BUILT_SOURCES} to list built headers
+(@pxref{Sources}). This causes them to be built before any other
+other build rules are run. This is unsatisfactory as a general
+solution, however in practice it seems sufficient for most actual
+programs.
@end itemize
-This code has not yet been in an official release of Automake. So,
-while it has seen some testing, it has not been stressed the way that
-the other implementations were. The most serious problems probably
-remain unknown.
+This code is used since Automake 1.5.
+
+In GCC 3.0, we managed to convince the maintainers to add special
+command-line options to help Automake more efficiently do its job. We
+hoped this would let us avoid the use of a wrapper script when
+Automake's automatic dependency tracking was used with @command{gcc}.
+
+Unfortunately, this code doesn't quite do what we want. In
+particular, it removes the dependency file if the compilation fails;
+we'd prefer that it instead only touch the file in any way if the
+compilation succeeds.
+
+Nevertheless, since Automake 1.7, when a recent @command{gcc} is
+detected at @command{configure} time, we inline the
+dependency-generation code and do not use the @command{depcomp}
+wrapper script. This makes compilations faster for those using this
+compiler (probably our primary user base). The counterpart is that
+because we have to encode two compilation rules in @file{Makefile}
+(with or without @command{depcomp}), the produced @file{Makefile}s are
+larger.
@subsection Techniques for Computing Dependencies
@@ -8117,23 +8135,6 @@ new header bug.
@subsection Future Directions for Automake's Dependency Tracking
-In GCC 3.0, we managed to convince the maintainers to add special
-command-line options to help Automake more efficiently do its job. We
-hoped this would let us avoid the use of a wrapper script when
-Automake's automatic dependency tracking was used with @command{gcc}.
-
-Unfortunately, this code doesn't quite do what we want. In
-particular, it removes the dependency file if the compilation fails;
-we'd prefer that it instead only touch the file in any way if the
-compilation succeeds.
-
-Nevertheless, in a future (probably minor) release of Automake we hope
-to @command{make} it so that if @command{gcc} is detected at
-@command{configure} time, then we will inline the
-dependency-generation code and not require the use of a wrapper
-script. This will make compilations that much faster for those using
-this compiler (probably our primary user base).
-
Currently, only languages and compilers understood by Automake can
have dependency tracking enabled. We would like to see if it is
practical (and worthwhile) to let this support be extended by the user