package builder, that person rightfully expects to be able to override
any of these variables at build time.
-To get around this problem, automake introduces an automake-specific
+To get around this problem, Automake introduces an automake-specific
shadow variable for each user flag variable. (Shadow variables are
not introduced for variables like @code{CC}, where they would make no
sense.) The shadow variable is named by prepending @samp{AM_} to the
data.stamp} concurrently the build is likely to fail (for instance the
two rules will create @file{data.tmp}, but only one can rename it).
-Admittedly, such a weird situation does not happen during ordinary
+Admittedly, such a weird situation does not arise during ordinary
builds. It occurs only when the build tree is mutilated. Here
@file{data.c} and @file{data.h} have been explicitly removed without
also removing @file{data.stamp} and the other output files.
@code{make clean; make} will always recover from these situations even
with parallel makes, so you may decide that the recover rule is solely
-an help to non-parallel make users and leave things as-is. Fixing
-this requires some locking mechanism to ensure only one instance of
-the recover rule rebuilds @code{data.stamp}. One could imagine
-something along the following lines.
+to help non-parallel make users and leave things as-is. Fixing this
+requires some locking mechanism to ensure only one instance of the
+recover rule rebuilds @code{data.stamp}. One could imagine something
+along the following lines.
@example
data.c data.h data.w data.x: data.stamp