MantisBT - CMake
View Issue Details
0011533CMakeCMakepublic2010-11-29 05:222011-06-06 18:25
Alexander Ivaniuk 
David Cole 
normalblockalways
closedfixed 
PCWindows
CMake 2.8.3 
CMake 2.8.4CMake 2.8.4 
0011533: Custom build step in MSVS 10 fails
Custom build step that was correctly working in Visual Studio 2010 with CMake 2.8.1 fails with CMake 2.8.3.

I'm using Visual Studio 10. This morning after updating CMake to version 2.8.3 from 2.8.1 found that a custom build step of our project fails with message "The system cannot find the batch label specified - VCReportError". I opened property pages for the project and found that custom build step now looks like:

<command1>
if errorlevel 1 goto VCReportError
<command2>
if errorlevel 1 goto VCReportError
<command3>
if errorlevel 1 goto VCReportError

and really there is no label "VCReportError"!

I dug into the source of CMake and found that from version CMake 2.8.2 file cmLocalVisualStudioGenerator.cxx contains the following code

line:258
    script += "echo Error in " + errorMsg;
    script += newline_text;

    script += "goto VCReportError";
    script += newline_text;
    script += ")";
    }
    return script;

It looks like somebody was writing code for earlier versions of Visual Studio where AFAIN this label presents by default.

So:
1) it really breaks any build on MSVS 10 with present custom build step.
2) even if the code will be modified in the following way

    script += newline_text;

    script += "goto VCReportError";
    script += newline_text;
    script += ")";
    }
    if( we are generating project for MSVS 10 )
    {
      script += ":VCReportError";
      script += "echo A custom buildtool returned error code";
    }
    return script;

a build still may be broken. For example, we are relying on error codes from our tools and we are outputing customized error messages. So, adding "if errorlevel 1 goto VCReportError" after each command still will hurt us. But, of course, this may be not a good style of using CMake so I'm open to new ideas.

Thanks in advance :-)
No tags attached.
related to 0011184closed David Cole Build INSTALL can't pass. Ogre 3d in "Building Your Projects With CMake" 
Issue History
2010-11-29 05:22Alexander IvaniukNew Issue
2010-11-29 09:13David ColeAssigned To => David Cole
2010-11-29 09:13David ColeStatusnew => assigned
2010-12-09 10:52Brad KingNote Added: 0023844
2010-12-09 11:41David ColeTarget Version => CMake 2.8.4
2010-12-15 12:00David ColeRelationship addedrelated to 0011184
2010-12-15 12:00David ColeNote Added: 0024169
2010-12-17 11:40David ColeNote Added: 0024235
2010-12-17 11:40David ColeStatusassigned => resolved
2010-12-17 11:40David ColeFixed in Version => CMake 2.8.4
2010-12-17 11:40David ColeResolutionopen => fixed
2011-06-06 18:25David ColeStatusresolved => closed
2011-06-06 18:25David ColeNote Added: 0026730

Notes
(0023844)
Brad King   
2010-12-09 10:52   
The code in question was added here:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af92e723 [^]

and first released in CMake 2.8.2:

  $ git tag --contains af92e723
  v2.8.2
  v2.8.3

Clearly the goal is to make scripts exit early if any error codes occur just like in the Makefile and Xcode generators. If your tool succeeds, don't return an error. It won't work with other native build tools anyway.

I think the solution is your proposed

  if( we are generating project for MSVS 10 )
    {
    script += ":VCReportError";
    script += "echo A custom buildtool returned error code";
    }

but will have to be modified to not enter this block if there is no error.
(0024169)
David Cole   
2010-12-15 12:00   
I think there's a different label we can use here instead of VCReportError. Seems like VCEnd is used instead in VS10...

See related bug 0011184.
(0024235)
David Cole   
2010-12-17 11:40   
This code change, just now pushed to 'next', resolves this issue:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66e79175327249aa2f0c80f5bd4a360b5b628bff [^]

The fix should appear in the CMake 2.8.4 release. (And in nightly binaries starting tonight.)
(0026730)
David Cole   
2011-06-06 18:25   
Closing resolved issues that have not been updated in more than 3 months.