spaces in values. Without this change, the following valid
call broke due to parsing of .MAKEFLAGS in bsd.symver.mk:
cd /usr/src/lib/libc && make -n DEBUG_FLAGS="-DFOO -DBAR"
Spotted by: Igor Sysoev
Submitted by: Maxim Dounin, ru
MFC after: 1 week
from the .MAKEFLAGS global variable even if it's empty or
unset. This means setting MAKEFLAGS to just an empty string
in the latter case.
If not doing so, make(1) behaved inconsistently WRT MAKEFLAGS.
In particular, it would let a `-f foo' option down to sub-makes
if .MAKEFLAGS was unset. E.g.,
env MAKEFLAGS="-f mymakefile" make
would pass `-f mymakefile' down to sub-makes via their environment
(unless mymakefile added something to .MAKEFLAGS).
But any additional options appearing would change this behaviour to
not passing `-f mymakefile' to sub-makes, as in:
env MAKEFLAGS="-f mymakefile" make -D DUMMY
or
env MAKEFLAGS="-f mymakefile -D DUMMY" make
(unless mymakefile cleared .MAKEFLAGS).
Also make(1) would leave MAKEFLAGS at its initial value if the
makefile set .MAKEFLAGS to an empty value. I.e., it was impossible
to override MAKEFLAGS with an empty value. (Note well that makefiles
are not to touch MAKEFLAGS directly, they alter .MAKEFLAGS instead.
So make(1) can filter out things such as -f when copying MAKEFLAGS
to .MAKEFLAGS at startup. Direct modifications to MAKEFLAGS just go
nowhere.)
While the original intentions of the BSD make authors are somewhat
unclear here, the bug proves that NOT passing -f options down is
the settled behaviour because the opposite behaviour is totally
unreliable in the presence of any other options. In addition, not
passing down -f's found in the environment is consistent with doing
so WRT the command line.
Update the manpage accordingly and make the whole description of
MAKEFLAGS and .MAKEFLAGS more consistent as this change indeed
brings more consistency into the reliable behaviour of make(1).
Submitted by: ru (main.c)
Tested with: make world
explicitly rather than relying on name space pollution to pull it in
for us.
NB: The usage of INT_MIN is somewhat bogus and suspect to my eye, but this
commit doesn't address that issue.
The most important point is that -f option(s) are never copied from
.Ev MAKEFILE to .Va .MAKEFILE by make(1), which is consistent with
handling the command line. (-f silently sit in .Ev MAKEFILE and go
to make's children unless overwritten via .Va .MAKEFILE)
Bump .Dd.
This fixes infinite restart in the following case:
Makefile: foo
foo: bar
do-something
Unlike GNU make, BSD make considers "Makefile" node as remade even
if "foo" is up-to-date and was not actually rebuilt.
GNU make does not consider nodes without commands as remade if child nodes
were not actually rebuilt.
Most probably, more proper fix would be to bring BSD make behaviour in-line
with GNU make but this would be more intrusive change.
After reading Makefile and all the files that are included using .include
or .sinclude directives (source Makefiles) make considers each source
Makefile as a target and tries to rebuild it. Both explicit and implicit
rules are checked and all source Makefiles are updated if necessary. If
any of the source Makefiles were rebuilt, make restarts from clean state.
To prevent infinite loops the following source Makefile targets are
ignored:
- :: targets that have no prerequisites but have commands
- ! targets
- targets that have .PHONY or .EXEC attributes
- targets without prerequisites and without commands
When remaking a source Makefile options -t (touch target), -q (query
mode), and -n (no exec) do not take effect, unless source Makefile is
specified explicitly as a target in make command line.
Additionally, system makefiles and .depend are not considered as a
Makefiles that can be rebuilt.
Reviewed by: harti
error return from open(2), leading to an erroneous value of maxJobs and
a hung make when -f is standard input and -j is used.
PR: bin/101232
Submitted by: Nate Eldredge <nge@cs.hmc.edu>
looked for in the system make file directory or in the specified
-m paths instead of always looking in the other -I and .PATH
specified paths. (Commit log shamelessly stolen from NetBSD.)
Reviewed by: yar
