View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0012628 | CMake | CMake | public | 2011-12-15 06:20 | 2012-05-09 15:26 | ||||
Reporter | Colin Powers | ||||||||
Assigned To | Brad King | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Linux | OS | RHEL | OS Version | 6 | ||||
Product Version | CMake 2.8.4 | ||||||||
Target Version | CMake 2.8.7 | Fixed in Version | CMake 2.8.7 | ||||||
Summary | 0012628: CMake uses variable called ${OUTPUT}, causes problems when user tries to use a variable called ${OUTPUT} | ||||||||
Description | I just found one of our CMakeLists.txt with the following line: ADD_CUSTOM_TARGET(policy ALL echo DEPENDS ${OUTPUT} ) Where ${OUTPUT} was populated in a for loop like this: list(APPEND OUTPUT ${target}) The value of ${target} is not really important. It seems ${OUTPUT} was also being manipulated by CMake, and we found that in one of the produced makefiles (./policy/CMakeFiles/policy.dir/build.make) the following content was there unexpectedly: policy/CMakeFiles/policy: <build dir>/policy/Change\ Dir:\ <build dir>/CMakeFiles/CMakeTmp Run\ Build\ Command:/usr/bin/gmake\ "cmTryCompileExec/fast" /usr/bin/gmake\ -f\ CMakeFiles/cmTryCompileExec.dir/build.make\ CMakeFiles/cmTryCompileExec.dir/build gmake[1]:\ Entering\ directory\ `<build dir>/CMakeFiles/CMakeTmp' /usr/local/bin/cmake\ -E\ cmake_progress_report\ <build dir>/CMakeFiles/CMakeTmp/CMakeFiles\ 1 Building\ CXX\ object\ CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o /usr/local/bin/c++\ \ \ \ \ -o\ CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o\ -c\ <build dir>/CMakeFiles/CMakeTmp/testCXXCompiler.cxx Linking\ CXX\ executable\ cmTryCompileExec /usr/local/bin/cmake\ -E\ cmake_link_script\ CMakeFiles/cmTryCompileExec.dir/link.txt\ --verbose=1 /usr/local/bin/c++\ \ \ \ \ \ \ \ \ CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o\ \ -o\ cmTryCompileExec\ -rdynamic\ gmake[1]:\ Leaving\ directory\ `<build dir>/CMakeFiles/CMakeTmp' I guess this is perhaps content that ends up in ./CMakeFiles/CMakeOutput.log? In any case, ${OUTPUT} was perhaps not the best choice of variable name for us, and I am able to solve the problem by doing something more sensible. However, is it sensible for CMake to be using this variable name itself? Is this variable name reserved and is that documented anywhere? I had a quick look around and couldn't find anything. Searching for other instances of the problem was also difficult, as you might expect when your keyword is "output". For reference the actual error I was getting was on typing 'make': target pattern contains no `%' | ||||||||
Steps To Reproduce | Try adding somewhere sensible in your CMakeLists.txt: message("-- OUTPUT IS: ${OUTPUT}") Observe that it is populated with various content. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0027983) Colin Powers (reporter) 2011-12-15 06:29 |
Error message: policy/CMakeFiles/policy.dir/build.make:45: *** target pattern contains no `%'. Stop. Contents of build.make line 45 are as specified in the description. |
(0027984) Brad King (manager) 2011-12-15 08:00 |
It's quite likely that one of the CMake language Modules uses this variable and could simply be fixed to use a better name. Run CMake with the --trace option to get verbose output about command processing. That should tell you where it is used. |
(0027985) Colin Powers (reporter) 2011-12-15 08:19 |
Thanks Brad. It looks as though the variable appears in the following CMake Modules: CMakeDetermineCompilerABI.cmake CMakeTestCCompiler.cmake CMakeTestCXXCompiler.cmake It looks at first glance as though the variable is set by the first one and used in the latter two. |
(0027986) Brad King (manager) 2011-12-15 08:35 |
The use in CMakeDetermineCompilerABI.cmake is inside a FUNCTION() so it has its own scope. The uses in CMakeTestCCompiler.cmake and CMakeTestCXXCompiler.cmake are the offenders. This should fix it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f6985ac [^] |
(0029454) David Cole (manager) 2012-05-09 15:26 |
Closing resolved issues that have not been updated in more than 4 months. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2011-12-15 06:20 | Colin Powers | New Issue | |
2011-12-15 06:29 | Colin Powers | Note Added: 0027983 | |
2011-12-15 08:00 | Brad King | Note Added: 0027984 | |
2011-12-15 08:19 | Colin Powers | Note Added: 0027985 | |
2011-12-15 08:35 | Brad King | Note Added: 0027986 | |
2011-12-15 08:35 | Brad King | Status | new => resolved |
2011-12-15 08:35 | Brad King | Resolution | open => fixed |
2011-12-15 08:35 | Brad King | Assigned To | => Brad King |
2011-12-16 17:29 | David Cole | Fixed in Version | => CMake 2.8.7 |
2011-12-16 17:29 | David Cole | Target Version | => CMake 2.8.7 |
2012-05-09 15:26 | David Cole | Note Added: 0029454 | |
2012-05-09 15:26 | David Cole | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |