View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011938CMakeCMakepublic2011-03-08 01:302011-11-11 10:45
Reporterstrcasecmp 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformVisual Studio 2010OSWindows XPOS Version
Product VersionCMake 2.8.4 
Target VersionCMake 2.8.5Fixed in VersionCMake 2.8.5 
Summary0011938: CMake ADD_CUSTOM_COMMAND with working directory problem in Visual Studio 2010
DescriptionApparently (based on my searches) in Visual Studio 2010, all custom build targets for a given project get executed within the same batch file generated by VS. As a result, if a cmake custom command has a working directory set, the resultant "cd" in the build rule can interfere with subsequent custom build rules.

This becomes a problem that can't be easily worked-around when building Qt projects (the Qt macros create their own custom commands).

In the Qt example, I was able to confirm that the "cd" was the cause by adding a cd back to the ${CMAKE_CURRENT_BINARY_DIR} at the start of the failing custom command, or by modifying the QT4_CREATE_MOC_COMMAND macro to avoid using the WORKING_DIRECTORY.
Steps To ReproduceFor simplest reproduction (though, not the only way), the attached sample may be used. To cause this sample to trigger the problem, cmake must be run from a location within this project directory. This causes a relative path to be used for the cmake command used in the CMakeLists.txt custom build tool.

The layout is as follows:

simple/
simple/hello.in
simple/CMakeLists.txt
simple/build/

Extract/copy cmake into the simple/ directory and run from the build subdirectory:

..\cmakedir\bin\cmake-gui.exe ..

Generate a VS2010 project/solution.

Then attempt to build the resultant solution.

Additional InformationThis could probably be easily (and probably correctly) solved by having the VS2010 generator do a cd back to the current binary directory at the end of each custom command (or a pushd/popd pair).
TagsNo tags attached.
Attached Fileszip file icon simple.zip [^] (1,303 bytes) 2011-03-08 01:30

 Relationships

  Notes
(0025975)
Brad King (manager)
2011-03-30 17:01

 The attached example does not give me an error. However, I can reproduce this by changing the CMakeLists.txt file to:
cmake_minimum_required(VERSION 2.8)
project(FOO C)

add_custom_command(
  OUTPUT hello.tmp
  COMMAND "${CMAKE_COMMAND}" -E copy hello.in ${CMAKE_CURRENT_BINARY_DIR}/hello.tmp
  WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
  )

add_custom_command(
  OUTPUT hello.c
  COMMAND cd # prints out working directory
  COMMAND "${CMAKE_COMMAND}" -E copy hello.tmp hello.c
  DEPENDS hello.tmp
  )

add_executable(hello hello.c)


Indeed we see that the generation of hello.c starts in the wrong directory.
(0025976)
Brad King (manager)
2011-03-30 17:03

 The current layout of the custom command script is this:

cd c:/working/directory
c:
command1 ...
if errorlevel 1 goto :VCEnd
command2 ...
if errorlevel 1 goto :VCEnd
...
commandN ...
if errorlevel 1 goto :VCEnd


for N COMMANDs. We will need a new structure that uses setlocal/endlocal around the whole block but still manages to goto :VCEnd if any one command fails.
(0025977)
Brad King (manager)
2011-03-30 17:16
edited on: 2011-03-30 17:16

 This appears to work:

setlocal
cd c:\working\directory
c:
if errorlevel 1 goto :cmEnd
command1 ...
if errorlevel 1 goto :cmEnd
command2 ...
if errorlevel 1 goto :cmEnd
...
commandN ...
:cmEnd
endlocal
if errorlevel 1 goto :VCEnd


However, I do not know whether endlocal preserves errorlevel reliably on all versions of Windows.
(0026144)
strcasecmp (reporter)
2011-04-07 16:36

 It appears that endlocal doesn't preserve errorlevel, but the following link contains a work-around. (Note: I haven't personally tested this.)

http://code-bear.com/bearlog/2007/06/01/getting-the-exit-code-from-a-batch-file-that-is-run-from-a-python-program/ [^]
(0026150)
Brad King (manager)
2011-04-08 15:40

 This should fix it:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=06fcbc47 [^]
(0026164)
Brad King (manager)
2011-04-11 12:01

 Interesting reference:

http://stackoverflow.com/questions/3686837/why-are-my-custom-build-steps-not-running-in-visual-studio-2010 [^]
(0026165)
Brad King (manager)
2011-04-11 12:04

 Re 0011938:0026150: The new approach does not work with VS 7.1, so I needed to add another change to use the new approach only for VS 10:

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

The change in the original commit also did not preserve %errorlevel% so the :VCEnd block did not process the error correctly. Here is another new approach to fix that:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=234bae7a [^]
(0027769)
David Cole (manager)
2011-11-11 10:45

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2011-03-08 01:30 strcasecmp New Issue
2011-03-08 01:30 strcasecmp File Added: simple.zip
2011-03-30 17:00 Brad King Assigned To => Brad King
2011-03-30 17:00 Brad King Status new => assigned
2011-03-30 17:01 Brad King Note Added: 0025975
2011-03-30 17:03 Brad King Note Added: 0025976
2011-03-30 17:16 Brad King Note Added: 0025977
2011-03-30 17:16 Brad King Note Edited: 0025977
2011-04-07 16:36 strcasecmp Note Added: 0026144
2011-04-08 15:40 Brad King Note Added: 0026150
2011-04-11 12:01 Brad King Note Added: 0026164
2011-04-11 12:04 Brad King Note Added: 0026165
2011-04-12 10:26 Brad King Status assigned => resolved
2011-04-12 10:26 Brad King Resolution open => fixed
2011-04-12 10:26 Brad King Target Version => CMake 2.8.5
2011-06-17 18:35 David Cole Fixed in Version => CMake 2.8.5
2011-11-11 10:45 David Cole Note Added: 0027769
2011-11-11 10:45 David Cole Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team