MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013582CMakeCMakepublic2012-10-10 04:472014-02-10 10:44
ReporterBoian Petkantchin 
Assigned ToRobert Maynard 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformPCOSUbuntuOS Version12.04
Product VersionCMake 2.8.7 
Target VersionCMake 2.8.12Fixed in VersionCMake 2.8.12 
Summary0013582: configure_file: removal of generated config file does not trigger regeneration on make
DescriptionWe 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.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip cmake-config-regeneration-bug.zip (1,099) 2012-10-16 03:09
https://public.kitware.com/Bug/file/4522/cmake-config-regeneration-bug.zip
Issue History
Date ModifiedUsernameFieldChange
2012-10-10 04:47Boian PetkantchinNew Issue
2012-10-10 07:49Brad KingNote Added: 0031202
2012-10-14 13:55Boian PetkantchinNote Added: 0031231
2012-10-15 07:29Brad KingNote Added: 0031233
2012-10-16 03:09Boian PetkantchinFile Added: cmake-config-regeneration-bug.zip
2012-10-16 03:24Boian PetkantchinNote Added: 0031239
2012-10-16 08:57Brad KingNote Added: 0031245
2012-10-16 08:57Brad KingStatusnew => confirmed
2012-10-16 08:57Brad KingTarget Version => CMake 2.8.11
2012-10-16 08:57Brad KingSummaryconfigure_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:14Brad KingAssigned To => Robert Maynard
2013-04-05 15:14Brad KingStatusconfirmed => assigned
2013-05-17 09:33Robert MaynardTarget VersionCMake 2.8.11 => CMake 2.8.12
2013-06-25 08:58Brad KingNote Added: 0033377
2013-06-25 08:58Brad KingFixed in Version => CMake 2.8.12
2013-06-25 08:58Brad KingStatusassigned => resolved
2013-06-25 08:58Brad KingResolutionopen => fixed
2014-02-10 10:44Robert MaynardNote Added: 0035080
2014-02-10 10:44Robert MaynardStatusresolved => closed

Notes
(0031202)
Brad King   
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   
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   
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   
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   
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   
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   
2014-02-10 10:44   
Closing resolved issues that have not been updated in more than 4 months.