[cmake-developers] [CMake 0015395]: NMAKE circa MSVC6 + Unix Makefiles + big project = "fatal error U1054: cannot create inline file"

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=15395 
====================================================================== 
Reported By:                Daniel Richard G.
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   15395
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2015-02-09 14:57 EST
Last Modified:              2015-02-09 14:57 EST
====================================================================== 
Summary:                    NMAKE circa MSVC6 + Unix Makefiles + big project =
"fatal error U1054: cannot create inline file"
Description: 
I am building a large project using CMake 3.1.2 with the Visual Studio 6
toolchain. As the IDE has not proven stable for automated building, I am using
the Unix Makefiles generator with NMAKE+CL.

The project build consistently fails part-way through with an error of the form

    [ 35%] Building C object src/lib/CMakeFiles/foo.dir/bar/baz/baz_qux.c.obj
src\lib\CMakeFiles\foo.dir\build.make(66114) : fatal error U1054: cannot create
inline file 'C:\tmp\nmz02696'
    Stop.
    NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
Studio\VC98\BIN\NMAKE.EXE"' : return code '0x2'
    Stop.
    NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
Studio\VC98\BIN\nmake.exe"' : return code '0x2'
    Stop.

Here's what I found in my investigation:

Each time the build rules use an NMAKE-generated response file with the @<< ...
<< syntax, NMAKE creates a temporary file in the $TMP directory. The temporary
file name has the form nXXNNNNN, where X is a lowercase letter and N is a digit.
The first temp file created is e.g. nma12345, then nmb12345, nmc12345. (The
numerical part appears to be random, but is consistent for all temp files
belonging to the same NMAKE instance. It does not appear to be a PID, but
effectively serves the same purpose.)

After a while, it gets to nna12345, then nzz12345, it wraps back to naa12345,
and then returns to nma12345. These files remain on the filesystem until the
originating NMAKE process exits. So in theory, that is a maximum of 26*26 == 676
distinct temp file names that this version of NMAKE can use. Knowing that, the
error above is obvious: NMAKE tried to write to an existing temp file that was
still in use, and failed.

I am able to work around this problem by invoking the following bit of Perl on
the CMake-generated build.make file:

    perl -pi.orig -e 'BEGIN{$i=0}
s!(\@<<)(?=\r?\n)!"$1\$(TMP)\\nmake-".($i++).".tmp"!e'
/path/to/CMakeFiles/myproject.dir/build.make

This assigns explicit temp-file names to the @<< ... << response files, using a
naming scheme that does not top out at 676 entries. (It could still be improved,
to allow multiple instances of NMAKE to run simultaneously.)

Visual Studio 6 may be old, but it's still an effective way to build code that
links against the original MSVCRT.DLL. CMake would benefit from knowing its way
around this limitation.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2015-02-09 14:57 Daniel Richard G.New Issue                                    
======================================================================