Changes in Nmake 8.0

dcook — Wed, 21 Mar 2007 05:07:00 GMT

I've run into this issue twice now (in different forms) after upgrading build systems from old versions of Nmake to Nmake 8.0 (the version from Visual Studio 2005), so I think that means it's time to blog about it.

Scenario 1:

Your stuff builds ok, but the output is totally wrong. Characters are missing from the output, and during the build, your computer keeps beeping at you.

Compiling .._koho.c ..\gaimem.c ..\k_area.c ..\k_clearn.c ..\k_grbg.c ..\k_hnkn.c ..\k_moji.c ..\k_regist.c . evconv.c ..♂lbmgr.c ..nvdbg.c ..\k_frame.c ..\k_kenti.c ..\k_disp.c ..\k_atwid.c ..\k_crsr.c ..\k_kkti.c .. ngmgr.c ..\k_koho.c ..\k_bun mk.c ..comment.c ..utotune.c ..

Investigating, you find that all of the missing characters are C-style escape sequences - "\a", "\r", "\n", etc., and the escape sequences have been replaced by the corresponding control code - beep, CR, LF, etc. So why did nmake suddenly decide to start processing escape codes?

Scenario 2:

The following is something of an idiom for makefiles. It shows the command line that is about to be executed, then executes it. (This is a bit of a simplification. As presented, this serves no purpose, but the pattern becomes useful when inline response files are involved.)

.cpp.obj:
  @type <<
  $(CL_COMMAND_LINE)
<<NOKEEP
  $(CL_COMMAND_LINE)

After upgrading to Nmake 8.0, this starts causing an error. Type complains that it can't find the temporary inline file. Replacing "type" with "cmd /c type" fixes the problem.

Both issues have essentially the same root cause. Tune in next time for the solution.

Where are we going, and what's with the handbasket? : build

Changes in Nmake 8.0