共用方式為


Changes in Nmake 8.0

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.

Comments

  • Anonymous
    March 24, 2007
    In my previous post , I described two issues encountered after updating our build system to Nmake 8.0