Alcatel-Lucent nmake Product Builder Alcatel-Lucent

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:

    include/hello.h [Feb 10 09:35:32 2000] has changed [Feb 10 09:35:18 2000]
    + ppcc -i /tools/nmake/sparc5/lu3.2/lib/cpp cc -O -I-D/tools/nmake/sparc5
    /lu3.2/lib/probe/C/pp/D586199Dobincc -Iinclude -I- -c hello.c
    + ppcc -i /tools/nmake/sparc5/lu3.2/lib/cpp cc -O -o hello hello.o

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.

Last Update: Wednesday,20-Dec-06 13:22:00 CST