two small manual updates

[Alexandre Duret-Lutz]

Unless someone shouts "NO!", I'd like to commit this in a few days.

2003-02-25  Alexandre Duret-Lutz  <address@hidden>

        * doc/autoconf.texi (Limitations of Make): Remove the section
        about `$<' in inference rules, it was a bogus interpretation of
        an old Automake change.  Discuss NetBSD, FreeBSD, OpenBSD, and
        Tru64 make in the "target lookup" section.
        (Automake): Automake 1.5+ no longer requires special tools to be
        present on the developer's host.

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.720
diff -u -r1.720 autoconf.texi
--- doc/autoconf.texi   25 Feb 2003 06:45:37 -0000      1.720
+++ doc/autoconf.texi   25 Feb 2003 22:17:25 -0000
@@ -631,14 +631,6 @@
 in @file{/usr/local/bin} (or whatever prefix was given to
 @command{configure}, if not @file{/usr/local}).
 
-Automake may require that additional tools be present on the
address@hidden's} machine.  For example, the @code{Makefile.in} that
-the developer works with may not be portable (e.g., it might use special
-features of your compiler to automatically generate dependency
-information).  Running @code{make dist}, however, produces a
address@hidden package (or whatever the program/version is)
-with a @code{Makefile.in} that will work on any system.
-
 The benefits of Automake increase for larger packages (especially ones
 with subdirectories), but even for small programs the added convenience
 and portability can be substantial.  And that's not address@hidden
@@ -11021,36 +11013,6 @@
 1994 and the context has been lost.  It's probably about SunOS 4.  If
 you can reproduce this, please send us a test case for illustration.)
 
address@hidden @code{$<} in inference rules:
address@hidden suffix rules, @code{$<}, and @code{VPATH}
address@hidden @code{$<}, inference rules, and @code{VPATH}
address@hidden @code{VPATH}, inference rules, and @code{$<}
-One implementation of @command{make} would not prefix @code{$<} if this
-prerequisite has been found in a @code{VPATH} dir.  This means that
-
address@hidden
-VPATH = ../src
-.c.o:
-        cc -c $< -o $@@
address@hidden example
-
address@hidden
-would run @code{cc -c foo.c -o foo.o}, even if @file{foo.c} was actually
-found in @file{../src/}.
-
-This can be fixed as follows.
-
address@hidden
-VPATH = ../src
-.c.o:
-        cc -c `test -f $< || echo ../src/`$< -o $@@
address@hidden example
-
-This kludge was introduced in Automake in 2000, but the exact context
-have been lost.  If you know which @command{make} implementation is
-involved here, please drop us a note.
-
-
 @item @code{$<} not supported in explicit rules
 @cindex explicit rules, @code{$<}, and @code{VPATH}
 @cindex @code{$<}, explicit rules, and @code{VPATH}
@@ -11059,7 +11021,7 @@
 As said elsewhere, using @code{$<} in explicit rules is not portable.
 The prerequisite file must be named explicitly in the rule.  If you want
 to find the prerequisite via a @code{VPATH} search, you have to code the
-whole thing manually.  For instance, using the same pattern as above:
+whole thing manually.  For instance, using the following pattern:
 
 @example
 VPATH = ../src
@@ -11199,6 +11161,7 @@
         done
 @end example
 
+Automake does something similar.
 
 @item OSF/Tru64 @command{make} creates prerequisite directories magically
 @cindex @code{VPATH} and prerequisite directories
@@ -11245,12 +11208,16 @@
 If a target does not need to be rebuilt, @acronym{GNU} @command{make} uses the
 filename found during the @code{VPATH} search.
 
-Other @command{make} implementations, like BSD @command{make}, are
+Other @command{make} implementations, like NetBSD @command{make}, are
 easier to describe: the filename found during the @code{VPATH} search
 will be used whether the target needs to be rebuilt or not.  Therefore
 new files are created locally, but existing files are updated at their
 @code{VPATH} location.
 
+OpenBSD and FreeBSD @command{make}s, however, will never perform a
address@hidden search for a dependency which has an explicit rule.
+This is extremely annoying.
+
 When attempting a @code{VPATH} build for an autoconfiscated package
 (e.g, @code{mkdir build; ../configure}), this means the @acronym{GNU}
 @command{make} will build everything locally in the @file{build}
@@ -11268,11 +11235,32 @@
 % @kbd{make}        # GNU make
 Building foo.x
 Building bar.x
-% @kbd{pmake}       # BSD make
+% @kbd{pmake}       # NetBSD make
 Building foo.x
 Building ../bar.x
+% @kbd{fmake}       # FreeBSD make, OpenBSD make
+Building foo.x
+Building bar.x
+% @kbd{tmake}       # Tru64 make
+Building foo.x
+Building bar.x
+% @kbd{touch ../bar.x}
+% @kbd{make}        # GNU make
+Building foo.x
+% @kbd{pmake}       # NetBSD make
+Building foo.x
+% @kbd{fmake}       # FreeBSD make, OpenBSD make
+Building foo.x
+Building bar.x
+% @kbd{tmake}       # Tru64 make
+Building foo.x
+Building bar.x
 @end example
 
+Note how NetBSD @command{make} updates @file{../bar.x} in its VPATH
+location, and how FreeBSD, OpenBSD, and Tru64 @command{make} always
+update @file{bar.x}, even when @file{../bar.x} is up to date.
+
 Another point worth mentioning is that once @acronym{GNU} @command{make} has
 decided to ignore a @code{VPATH} filename (e.g., it ignored
 @file{../bar.x} in the above example) it will continue to ignore it when
@@ -11299,16 +11287,26 @@
 cp bar.x bar.y
 cp: cannot stat `bar.x': No such file or directory
 make: *** [bar.y] Error 1
-% @kbd{pmake}       # BSD make
+% @kbd{pmake}       # NetBSD make
 Building ../bar.x
 cp ../bar.x bar.y
+% @kbd{rm bar.y}
+% @kbd{fmake}       # FreeBSD make, OpenBSD make
+echo Building bar.x
+cp bar.x bar.y
+cp: cannot stat `bar.x': No such file or directory
+*** Error code 1
+% @kbd{tmake}       # Tru64 make
+Building bar.x
+cp: bar.x: No such file or directory
+*** Exit 1
 @end example
 
 Note that if you drop away the command from the @code{bar.x: newer.x}
-rule, things will magically start to work: @acronym{GNU}
address@hidden knows that @code{bar.x} hasn't been updated, therefore
-it doesn't discard the result from @code{VPATH} (@file{../bar.x}) in
-succeeding uses.
+rule, @acronym{GNU} @command{make} will magically start to work: it
+knows that @code{bar.x} hasn't been updated, therefore it doesn't
+discard the result from @code{VPATH} (@file{../bar.x}) in succeeding
+uses.  Tru64 will also work, but FreeBSD and OpenBSD still don't.
 
 @example
 % @kbd{cat Makefile}
@@ -11323,9 +11321,21 @@
 % @kbd{make}        # GNU make
 cp ../bar.x bar.y
 % @kbd{rm bar.y}
-% @kbd{pmake}       # BSD make
+% @kbd{pmake}       # NetBSD make
+cp ../bar.x bar.y
+% @kbd{rm bar.y}
+% @kbd{fmake}       # FreeBSD make, OpenBSD make
+cp bar.x bar.y
+cp: cannot stat `bar.x': No such file or directory
+*** Error code 1
+% @kbd{tmake}       # True64 make
 cp ../bar.x bar.y
 @end example
+
+It seems the sole solution that would please every @command{make}
+implementation is to never rely on @code{VPATH} searches for targets.
+In other words, @code{VPATH} should be reserved to unbuilt sources.
+
 @end table
 @c end item about VPATH
 

-- 
Alexandre Duret-Lutz