MantisBT - CMake
View Issue Details
0014030CMakeCMakepublic2013-03-19 22:432013-10-07 10:04
Paul "TBBle" Hampson 
 
normalminoralways
closednot fixable 
Microsoft Visual StudioMicrosoft Windows7 SP1
CMake 2.8.10.2 
 
0014030: INCLUDE( file OPTIONAL ) doesn't see the "file appeared" as "file changed"
Using the Visual Studio generators, I get a free rerun of CMake whenever I build my project.

One of the project pre-build steps generates a CMake include file which is included with
INCLUDE( file OPTIONAL )

However, even though this file has gone from non-existent to existent, CMake doesn't consider that to be a change, and doesn't regenerate the projects.

If I then delete my build-tree and rerun CMake, subsequent _changes_ to the generated file are seen as changes by CMake correctly.
(Only tested with Visual Studio Generator's auto-rebuild, sorry. I don't know if that's a factor.)

Include a non-existent file with INCLUDE( file OPTIONAL )
Generate a Visual Studio solution using CMake.
Create the non-existent file
Build the project in Visual Studio

- Expected result: CMake re-runs, processing the included file.
- Actual result: CMake doesn't see anything as changed, and does nothing.

===== Comparison with the success case:

Include a existing file with INCLUDE( file OPTIONAL )
Generate a Visual Studio solution using CMake.
Modify the existing file
Build the project in Visual Studio

- Expected result: CMake re-runs, processing the included file.
- Actual result: CMake re-runs, processing the included file.
No tags attached.
Issue History
2013-03-19 22:43Paul "TBBle" HampsonNew Issue
2013-03-20 09:10Brad KingNote Added: 0032679
2013-03-20 09:10Brad KingStatusnew => resolved
2013-03-20 09:10Brad KingResolutionopen => not fixable
2013-03-20 23:10Paul "TBBle" HampsonNote Added: 0032681
2013-03-20 23:10Paul "TBBle" HampsonStatusresolved => feedback
2013-03-20 23:10Paul "TBBle" HampsonResolutionnot fixable => reopened
2013-03-21 07:02David ColeNote Added: 0032682
2013-03-21 11:51Brad KingNote Added: 0032683
2013-03-21 11:51Brad KingStatusfeedback => resolved
2013-03-21 11:51Brad KingResolutionreopened => not fixable
2013-10-07 10:04Robert MaynardNote Added: 0034012
2013-10-07 10:04Robert MaynardStatusresolved => closed

Notes
(0032679)
Brad King   
2013-03-20 09:10   
This is not possible to implement. There is no way to express a dependency on the non-existence of a file without a much more sophisticated underlying native build tool than make, msbuild, or vcbuild.

This is the same reason we recommend explicitly listing all sources rather than using file(GLOB) to collect them. When a new source appears then CMake knows to re-run only if the CMakeLists.txt file has changed to list it. Otherwise one must explicitly re-run CMake by hand.

(0032681)
Paul "TBBle" Hampson   
2013-03-20 23:10   
Avoiding GLOB() is exactly what I'm trying to do here.

Sources are generated by a script, based on other arbitrary files, which also generates an explicit listing of the files in question for CMake to include.

What's the actual correct way to handle this case? My only other idea is to have the script be run by CMake at CMake time, and _again_ as a pre-build step in the generated build scripts.
(0032682)
David Cole   
2013-03-21 07:02   
Make sure the file always exists instead of using OPTIONAL. If you include an *empty* file, then it will change when you modify it later, rather than popping into existence.

Something like this:

  set(file "${CMAKE_CURRENT_BINARY_DIR}/includedFile.cmake")
  if(NOT EXISTS "${file}")
    file(WRITE "${file}" "")
  endif()
  include(${file})

Be warned, though, if you write a new version of this file as some sort of build step output, you will likely still have problems in Visual Studio. It "doesn't like it" when it detects that CMake has to re-run during the middle of a build, and generates new solution and/or vc(x)proj files...

It's better to make sure that included files are written/generated properly before/during CMake's configure step.
(0032683)
Brad King   
2013-03-21 11:51   
Discussion of this nature belongs on the mailing list where it will have a broader audience.
(0034012)
Robert Maynard   
2013-10-07 10:04   
Closing resolved issues that have not been updated in more than 4 months.