The first thing to know is the nmake -e (explain) flag, which
causes nmake to provide output "explaining" why it is taking certain
actions. If things rebuild when you think they shouldn't try running
nmake -e' and examine the output (it is not nearly as rough
as the debug output.) The following example shows that hello.c was
recompiled because an included header file had changed:
$ nmake -e include/hello.h [Aug 13 15:48:53 2010] has changed [Aug 13 15:46:41 2010] + gcc -O -Iinclude -I- -c hello.c + gcc -O -o hello hello.o
Have you ever wanted the explain output for a finished build but it is too
late to use the
Release nmake 12 introduced a feature to
capture triggered target explain data.
By default the explain data is captured in the statefile and can be viewed by
dumping the data from the statefile. The following example shows the
hello targets were updated because
hello.h changed. Notice that the statefile is specified on
the command line, not the makefile.
$ nmake -lef Makefile.ms /* Explain */ hello : include/hello.h [Aug 13 15:48:53 2010] has changed [Aug 13 15:46:41 2010] hello.o : include/hello.h [Aug 13 15:48:53 2010] has changed [Aug 13 15:46:41 2010]
The explain data is also captured by default in structured build logs when using the xmakelog command, and is included in the web base logs generated by buildlog2html. For details see the Structured Build Log page.
Most often unnecessary rebuilds are caused by problems in the makefiles. Typical mistakes are the following:
XXX : YYY somecommand $(*) > $(<) mv $(<) ../../../bin/$(<)From the target name "XXX", nmake assumes the file ./XXX will be generated. However the shell action specifically moves the file into a different directory. When the next build runs nmake sees file "./XXX" is missing so it tries to regenerate it. The above assertion should really be defined as follows:
../../../bin/XXX : YYYWith the proper assertion nmake will know what file is generated. However, this style may cause more confusion because other references to "XXX" must now be "../../../bin/XXX" in order to generate the file (eg. ":ALL: ../../../bin/XXX").
Including the same header in an inconsistent manor in multiple source files managed by the same makefile may cause code to rebuild. For example, one peice of code may use the follwing include directive:
While other code uses the more correct directive:
This inconsistency can cause nmake to rebuild some of the files in the makefile. In this example changing the first source file to use <sys/wait.h> will solve the problem.
There is a known problem in release 3.1.2 which may cause files to rebuild under the conditions below. The problem is fixed in release lu3.2.
If you still cannot figure out why things are rebuilding send details to technical support, we will help you identify the cause of such problems.