Alcatel-Lucent nmake Product Builder
Persistent State
Feature Description
A statefile is created when nmake finishes processing a makefile. The statefile contains the current nmake execution status including such things as target dependency information, variable definitions, time-stamps, etc. The statefile is used to minimize work on later calls to nmake. The information in the statefile is used to determine when something is out-of-date and must be regenerated. Maintaining a persistent state is essential for viewpathing.
Impact
Performance
- Allows nmake to quickly recover the previous build state.
Build Accuracy
- Files are deemed out-of-date if their time-stamp changes, either becoming newer or older. If the time-stamp becomes older a warning message is issued and the affected targets are updated.
- Changes in variable values can trigger files to be updated. Such as changing the compiler tools, compiler flags, macro definitions, etc.
- Changes to a rule's shell action will trigger the associated targets to be updated with the new action.
Consequence of Not Having the Feature
- Important changes to the makefile, such as compiler flags and rule changes, will not automatically update the affected targets. Such changes will require a forced rebuild to guarantee the necessary files are updated. This complicates build maintenance and introduces the possibility of errors.
- Targets can be written to and corrupted outside of the build system and they will not be rebuilt in the next build since its time-stamp will still be newer than the prerequisites. nmake will notice any time-stamp change and rebuild the affected targets.
- Swapping an older source node into the viewpath would not trigger the necessary update to make the targets consistent with the current code. Detecting this case is particularly important in a viewpathing environment.
Examples
Example 1 - Inconsistent Target
The first example shows that touching the target after it is updated
will force it out-of-date, even though its time-stamp is still newer
than the source and object files. The nmake -e flag tells
nmake to explain why it is taking action.
/*** Makefile ***/ CCFLAGS = -g abc :: a.c
$ nmake + cc -g -I- -D_TRACE_ -c a.c + cc -g -o abc a.o $ ls -l total 212 -rw-r--r-- 1 richb richb 44 Aug 21 16:55 Makefile -rw-r--r-- 1 richb richb 5835 Aug 21 16:58 Makefile.mo -rw-r--r-- 1 richb richb 14210 Aug 21 16:58 Makefile.ms -rw-r--r-- 1 richb richb 84 Aug 21 16:52 a.c -rw-r--r-- 1 richb richb 3532 Aug 21 16:58 a.o -rwxr-xr-x 1 richb richb 180224 Aug 21 16:58 abc $ echo junk > abc $ ls -l total 32 -rw-r--r-- 1 richb richb 44 Aug 21 16:55 Makefile -rw-r--r-- 1 richb richb 5835 Aug 21 16:58 Makefile.mo -rw-r--r-- 1 richb richb 14210 Aug 21 16:58 Makefile.ms -rw-r--r-- 1 richb richb 84 Aug 21 16:52 a.c -rw-r--r-- 1 richb richb 3532 Aug 21 16:58 a.o -rwxr-xr-x 1 richb richb 5 Aug 21 16:58 abc $ nmake -e abc [Aug 21 16:58:35 2003] has changed [Aug 21 16:58:25 2003] + cc -g -o abc a.o
Changing the compile flags will trigger an update.
/*** Makefile ***/ CCFLAGS = -O abc :: a.c
$ ls -l total 212 -rw-r--r-- 1 richb richb 44 Aug 21 17:00 Makefile -rw-r--r-- 1 richb richb 5835 Aug 21 16:58 Makefile.mo -rw-r--r-- 1 richb richb 14236 Aug 21 16:58 Makefile.ms -rw-r--r-- 1 richb richb 84 Aug 21 16:52 a.c -rw-r--r-- 1 richb richb 3532 Aug 21 16:58 a.o -rwxr-xr-x 1 richb richb 180224 Aug 21 16:58 abc $ nmake -e state variable (IFFEFLAGS) changed to `set cc cc -O : set static - dn : ' from `set cc cc -g -D_TRACE_ : set static -dn : ' state variable (CCFLAGS) changed to `-O' from `-g' . [Aug 21 17:00:28 2003] has changed [Aug 21 16:58:22 2003] + cc -O -I- -c a.c + cc -O -o abc a.o
Example 2 - Rule Action Change
The next example shows that changing a rule will update the affected files. A new makefile will be used for this example.
/*** Makefile ***/
:ALL: t1 t2
t1 : abc
cp $(*) $(<)
t2 : xyz
cp $(*) $(<)
$ nmake + cp abc t1 + cp xyz t2
Now we change the shell action for t1. t1 will be
updated but t2 will not.
/*** Makefile ***/
:ALL: t1 t2
t1 : abc
cp $(*) $(<)
echo endfile >> $(<)
t2 : xyz
cp $(*) $(<)
$ nmake -e t1 action changed [#3] + cp abc t1 + echo endfile + 1>> t1
Example 3 - Viewpath
The last example shows how swapping in an older source node in the viewpath will trigger an update. In this case the time-stamp of the target is still newer than the source code. nmake detects the change and updates the targets.
In this example all the source code is under the src2.0 node and we are building in the bld node.
$ pwd /home/richb/bld $ export VPATH=/home/richb/bld:/home/richb/src2.0 $ ls -l total 0 $ ls -l ../src2.0 total 4 -rw-r--r-- 1 richb richb 24 Apr 21 2005 Makefile -rw-r--r-- 1 richb richb 79 Apr 21 2005 hello.c -rw-r--r-- 1 richb richb 42 Apr 21 2005 main.c $ nmake + cc -O -I- -c /home/richb/src2.0/main.c + cc -O -I- -c /home/richb/src2.0/hello.c + cc -O -o hello main.o hello.o
Now the src1.0 node is swapped in the viewpath. Notice the time-stamps of the source files are older than those from src2.0.
$ export VPATH=/home/richb/bld:/home/richb/src1.0 $ ls -l total 44 -rw-r--r-- 1 richb richb 6400 Nov 23 09:56 Makefile.mo -rw-r--r-- 1 richb richb 16759 Nov 23 09:56 Makefile.ms -rwxr-xr-x 1 richb richb 6684 Nov 23 09:56 hello -rw-r--r-- 1 richb richb 1304 Nov 23 09:56 hello.o -rw-r--r-- 1 richb richb 1152 Nov 23 09:56 main.o $ ls -l ../src1.0 total 4 -rw-r--r-- 1 richb richb 24 Oct 8 2003 Makefile -rw-r--r-- 1 richb richb 79 Oct 8 2003 hello.c -rw-r--r-- 1 richb richb 42 Oct 8 2003 main.c $ nmake make: warning: main.c has been replaced by an older version make: warning: hello.c has been replaced by an older version + cc -O -I- -c /home/richb/src1.0/main.c + cc -O -I- -c /home/richb/src1.0/hello.c + cc -O -o hello main.o hello.o