To avoid that, we now do ::[+?!]*= but the SysV = modifier can
conflict with any new modifier. At there are currently no Makefiles
in our tree that use ${FOO::=bar}
problems such as using modifiers on .for loop iterators derived from
local variables (eg .TARGET).
Unless the variable already exists in a global context, these assignments are
local to the current context (this is usually what is wanted).
is an empty list, use DEFSYSPATH.
The current behaviour may have been useful when DEFSYSMK was an
absolute path (hasn't been the case since 1996), but right now
make -m /no/such/dir will fail to find sys.mk and die.
These allow some very useful magic in the makefiles.
The comment in var.c describing their behaviour is mostly lifted
from ODE make, but the implementation of the modifiers themselves
is quite different (much simpler) due to divergence of our code base.
Firstly, we ignore getenv("PWD") if MAKEOBJDIRPREFIX is set so that we always
get the same value for .CURDIR regardless of how make was invoked.
Second, when executing a command we check if it is ${.MAKE} or ${.MAKE:T}
without a preceeding chdir, if so we insert a chdir(${.CURDIR}) so that
the Makefile will be found by the child make. Note that this behaviour is
dissabled if MAKEOBJDIRPREFIX is not set or if NOCHECKMAKECHDIR is set.
See the comments in main.c for more detail.
With these two changes, one can successfully build usr/src using MAKEOBJDIRPREFIX
allowing the src to be mounted from a CD-ROM.
someone wants to do freaky stuff with $MAKEOBJDIR.
Initialize the Var system and set .CURDIR, MACHINE and MACHINE_ARCH
before chdir_verify_path() is called.
list of target nodes returned by Make_ExpandUse(). We have to search the
cohorts explicitly while iterating through the tree. So, tweak CompatMake()
to do this.
can (i.e., everything except environment variables, which aren't
stored in hash tables).
While we're here, inline the body of VarDelete into Var_Delete since
it's the only caller and it's just simpler that way when v->name can
share storage with the hash entry and may not need to be freed
separately.
Speeds up the infamous libc build benchhmark maybe 1% on PIII, 4% on
alpha pc164
Suggested by Perry Metzger.
Build a list of `cohorts' as before, but do *not* link each one into all the
parent nodes; instead, copy the `cohort' lists into the stream of targets to
be built inside Make_ExpandUse(). Also do the attribute propagation as a
separate pass after parsing.
This eliminates several O(n^2) algorithms.
passing in the LstNode of the child being inspected. Shaves off another few %,
particularly when there are long child lists containing $ expansions (e.g. in
libc).
in the presence of .PATH directives by specifying:
.PATH: .DOTLAST
This will be used to fixup the build system to work with both crypto-us
and crypto-intl sub-trees.
Make(1) changes by Christos Zoulas, after much badgering by me :-)
parents would be get remade, even if children were not really updated
by the commands executed for them. It also makes all the children have
the real modification time set if possible, so it should fix some other
timing weirdnesses...
- collapse childMade and make fields into flags and convert them to bits
CHILDMADE and REMAKE
- introduce FORCE flag that gets set in all the parents of a child that
has no sources and does not exist.
- set oodate if the FORCE flag is set, and not if CHILDMADE
- centralize the RECHECK into Make_Recheck() and use this in make.c and compat.c
- use Make_TimeStamp for all child -> parent timestamp propagations
a union mount.
eg.
src: FORCE
FORCE is a fake target that does not have sources. When FORCE is
considered made it gets updated with the current timestamp. If the
directory happens to have the same timestamp too, then it will not
be made because it is considered to be up-to-date with respect to
the child. This can happen because the time resolution is only in
seconds. It is more likely to happen on a union filesystem where
the timestamps take longer to update.
The fix is to consider the parent unmade when children have been
updated.
the previous garbage bytes may be read.
Example: "make n" --- target = n, suffix = .ln
Changing interface of SuffSuffIsSuffix() is required to fix this bug.