Alcatel-Lucent nmake Product Builder

Why do my files rebuild when nothing has changed?

nmake can explain

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

Captured explain messages

Have you ever wanted the explain output for a finished build but it is too late to use the -e option? 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.o and 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.

Makefile issues

Most often unnecessary rebuilds are caused by problems in the makefiles. Typical mistakes are the following:

• Virtual targets (a target that does not actually get generated) are used without the .VIRTUAL atom. This leads nmake to believe the target needs remade because it doesn't exist on the next build.
• Targets are moved or built into a different directory as part of an action without nmake knowing. For example, lets say you build file XXX from file YYY as follows:

  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 : YYY
  

  With 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").

Source code issues

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:

    #include </usr/include/sys/wait.h>

While other code uses the more correct directive:

    #include <sys/wait.h>

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.

Release 3.1.2 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.

1. State variables are defined in the makefile and used as defines in the source code.
2. You are building in a new node added to the top of the VPATH.

Still rebuilding?

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.