View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0011938 | CMake | CMake | public | 2011-03-08 01:30 | 2011-11-11 10:45 | ||||
Reporter | strcasecmp | ||||||||
Assigned To | Brad King | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Visual Studio 2010 | OS | Windows XP | OS Version | |||||
Product Version | CMake 2.8.4 | ||||||||
Target Version | CMake 2.8.5 | Fixed in Version | CMake 2.8.5 | ||||||
Summary | 0011938: CMake ADD_CUSTOM_COMMAND with working directory problem in Visual Studio 2010 | ||||||||
Description | Apparently (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 Reproduce | For 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 Information | This 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). | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | simple.zip [^] (1,303 bytes) 2011-03-08 01:30 | ||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |