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