doc: extending dependency tracking not officially supported, with info.

* doc/automake.texi (Dependencies): link to Nick Bowler's message
about how to extend dependency tracking, with caveats.
https://lists.gnu.org/archive/html/automake/2025-07/msg00014.html
En passant, re-enable @setchapternewpage on.
* doc/automake-history.texi (Future Directions for Dependencies): link
to the new info.

diff --git a/doc/automake-history.texi b/doc/automake-history.texi
index 355e0d57c5c7a6a4450ff6d4e13dc3be042da1ba..17c679741caaebc261f6596a154ec4163334c62a 100644 (file)
--- a/doc/automake-history.texi
+++ b/doc/automake-history.texi
@@ -239,10 +239,10 @@ cpio_SOURCES = ...
 Extra files to distribute must be listed in @code{DIST_OTHER} (the
 ancestor of @code{EXTRA_DIST}).  Also extra directories that are to be
 distributed should appear in @code{DIST_SUBDIRS}, but the manual
-describes this as a temporary ugly hack (today extra directories should
+describes this as a temporary ugly hack. Today, extra directories should
 also be listed in @code{EXTRA_DIST}, and @code{DIST_SUBDIRS} is used
-for another purpose, @pxref{Conditional Subdirectories, , Conditional
-Subdirectories, automake, GNU Automake}).
+for another purpose (@pxref{Conditional Subdirectories,,, automake,
+GNU Automake}).
 
 @item 1995-11-26 Automake 0.21
 
@@ -1108,9 +1108,12 @@ new header bug.
 @subsection Future Directions for Dependencies
 
 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
-to languages unknown to Automake.
+have dependency tracking enabled.  Although it would be worthwhile to
+support extensions by the user to languages unknown to Automake, there
+are no plans to implement this (patches welcome).  Nevertheless,
+@pxref{Dependencies,,, automake, GNU Automake}, for information on
+how a user might do this now, albeit unofficially.
+
 
 @node Releases
 @chapter Release Statistics

diff --git a/doc/automake.texi b/doc/automake.texi
index 27b5203490af716ef3c10c5569132f3e765e85cd..fb2a9b5d854c2a56af05301e48b304a970747b56 100644 (file)
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -4,7 +4,7 @@
 @settitle automake
 @documentencoding UTF-8
 @documentlanguage en
-@setchapternewpage off
+@setchapternewpage on
 @c %**end of header
 
 @include version.texi
@@ -1355,7 +1355,7 @@ Although nesting packages isn't something we would recommend to
 someone who is discovering the Autotools, it is a nice feature worthy
 of mention in this small advertising tour.
 
-Autoconfiscated packages (that means packages whose build system have
+Autoconfiscated packages (meaning packages whose build system have
 been created by Autoconf and friends) can be nested to arbitrary
 depth.
 
@@ -7240,7 +7240,7 @@ suffix rule handling (@pxref{Suffixes}).
 @node Dependencies
 @section Automatic dependency tracking
 
-As a developer it is often painful to continually update the
+As a developer it is painful to continually update the
 @file{Makefile.am} whenever the include-file dependencies change in a
 project.  Automake supplies a way to automatically track dependency
 changes (@pxref{Dependency Tracking}).
@@ -7306,6 +7306,16 @@ else
 endif
 @end example
 
+Automake does not have support for extending the dependency tracking
+at runtime, e.g., if you want to have dependencies for a new language.
+However, Nick Bowler sketched how to do this in a message to the
+@code{automake} mailing list:
+@url{https://lists.gnu.org/archive/html/automake/2025-07/msg00014.html}.
+Although this necessarily uses various implementation details of
+Automake, and thus can't be considered future-proof, we don't have any
+plans or expectations for changing the dependency implementation in
+any substantive way.
+
 @node EXEEXT
 @section Support for executable extensions
 
@@ -7351,9 +7361,9 @@ program using such a substitution, then your @file{configure.ac} must
 take care to add @samp{$(EXEEXT)} when constructing the output variable.
 
 Sometimes maintainers like to write an explicit link rule for their
-program.  Without executable extension support, this is easy---you
-simply write a rule whose target is the name of the program.  However,
-when executable extension support is enabled, you must instead add the
+program.  Without executable extension support, you can simply write a
+rule whose target is the name of the program.  However, when
+executable extension support is enabled, you must instead add the
 @samp{$(EXEEXT)} suffix.
 
 This might be a nuisance for maintainers who know their package will