| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0013582 | CMake | CMake | public | 2012-10-10 04:47 | 2014-02-10 10:44 | ||||
| Reporter | Boian Petkantchin | ||||||||
| Assigned To | Robert Maynard | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | PC | OS | Ubuntu | OS Version | 12.04 | ||||
| Product Version | CMake 2.8.7 | ||||||||
| Target Version | CMake 2.8.12 | Fixed in Version | CMake 2.8.12 | ||||||
| Summary | 0013582: configure_file: removal of generated config file does not trigger regeneration on make | ||||||||
| Description | We have a project, which generates a configuration file. If the file is changed outside of CMake and then a make is issued, the configuration file is not regenerated. On the other hand, if cmake is issued in the binary directory, the configuration file is freshly regenerated. Shouldn't the generated config file be monitored for an outside change and regenerated if needed? After all, it is almost like another target during the build process. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |  cmake-config-regeneration-bug.zip [^] (1,099 bytes) 2012-10-16 03:09 | ||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0031202) Brad King (manager) 2012-10-10 07:49 |
I do this all the time. For example:$ cat ../CMakeLists.txt cmake_minimum_required(VERSION 2.8.7) project(Issue13582 NONE) configure_file(in.txt out.txt) $ cmake .. -- Configuring done -- Generating done -- Build files have been written to: .../Issue13582/b $ make $ touch ../in.txt $ make -- Configuring done -- Generating done -- Build files have been written to: .../Issue13582/b Please post a complete example tarball reproducing the problem. |
|
(0031231) Boian Petkantchin (reporter) 2012-10-14 13:55 |
It is not the in file, but the outputed config file, for example a header file. If it changes outside of CMake, it is not regenerated. I feel it should be regenerated, cause its owner is the CMake build system and the only appropriate way to change it is to change the configuration in file. |
|
(0031233) Brad King (manager) 2012-10-15 07:29 |
Please post a minimal but complete example source tree as a tarball that exactly demonstrates your case. Include instructions on what to build first, what to modify, and what you expect to happen. |
|
(0031239) Boian Petkantchin (reporter) 2012-10-16 03:24 |
Ok. Here is a small project that shows the bug: https://public.kitware.com/Bug/file/4522/cmake-config-regeneration-bug.zip [^] Steps to reproduce: Go to the unzipped folder in the console and execute the following commands: mkdir build && cd build cmake .. rm ../Config.h make Result: With the command "cmake .." the Config.h file is generated. Then after it is removed and "make" is issued it is not generated again. The compiler throws an error: "fatal error: Config.h: No such file or directory" Desired outcome: When "make" is called, the Config.h file should be regenerated if it has changed since the last build. My reasoning is that Config.h is owned by the CMake build system, so there is no reason not to regenerate it. The user should be aware, that he should not edit the file manually, but only through Config.h.in, since it could be rewritten at any time. |
|
(0031245) Brad King (manager) 2012-10-16 08:57 |
Try this patch: diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx index f067da4..7e89918 100644 --- a/Source/cmMakefile.cxx +++ b/Source/cmMakefile.cxx @@ -3304,6 +3304,7 @@ int cmMakefile::ConfigureFile(const char* infile, const char* outfile, std::string sinfile = infile; this->AddCMakeDependFile(infile); cmSystemTools::ConvertToUnixSlashes(soutfile); + this->AddCMakeOutputFile(soutfile.c_str()); mode_t perm = 0; cmSystemTools::GetPermissions(sinfile.c_str(), perm); std::string::size_type pos = soutfile.rfind('/'); |
|
(0033377) Brad King (manager) 2013-06-25 08:58 |
A patch based on that in 0013582:0031245 has been committed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad502502 [^] |
|
(0035080) Robert Maynard (manager) 2014-02-10 10:44 |
Closing resolved issues that have not been updated in more than 4 months. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2012-10-10 04:47 | Boian Petkantchin | New Issue | |
| 2012-10-10 07:49 | Brad King | Note Added: 0031202 | |
| 2012-10-14 13:55 | Boian Petkantchin | Note Added: 0031231 | |
| 2012-10-15 07:29 | Brad King | Note Added: 0031233 | |
| 2012-10-16 03:09 | Boian Petkantchin | File Added: cmake-config-regeneration-bug.zip | |
| 2012-10-16 03:24 | Boian Petkantchin | Note Added: 0031239 | |
| 2012-10-16 08:57 | Brad King | Note Added: 0031245 | |
| 2012-10-16 08:57 | Brad King | Status | new => confirmed |
| 2012-10-16 08:57 | Brad King | Target Version | => CMake 2.8.11 |
| 2012-10-16 08:57 | Brad King | Summary | configure_file: change in the generated config file does not triger regeneration on make => configure_file: removal of generated config file does not trigger regeneration on make |
| 2013-04-05 15:14 | Brad King | Assigned To | => Robert Maynard |
| 2013-04-05 15:14 | Brad King | Status | confirmed => assigned |
| 2013-05-17 09:33 | Robert Maynard | Target Version | CMake 2.8.11 => CMake 2.8.12 |
| 2013-06-25 08:58 | Brad King | Note Added: 0033377 | |
| 2013-06-25 08:58 | Brad King | Fixed in Version | => CMake 2.8.12 |
| 2013-06-25 08:58 | Brad King | Status | assigned => resolved |
| 2013-06-25 08:58 | Brad King | Resolution | open => fixed |
| 2014-02-10 10:44 | Robert Maynard | Note Added: 0035080 | |
| 2014-02-10 10:44 | Robert Maynard | Status | resolved => closed |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |