[cmake-developers] configure_file() missing output file regeneration

[Brad King]

On 07/31/2014 09:12 AM, Nils Gladitz wrote:
>> No need for that.  Just do "git grep GetOutputFiles" and you will
>> see that no generators even query that except Makefile and Ninja.
>> Therefore Xcode and VS generators are missing this support.
> 
> Are they intentionally left out?

I don't think so.  However, see below.

Actually I just dug in to the history of this and found that the whole
feature was attempted and reverted in 2006:

 ENH: add support for re-running cmake if the cmakefiles change, 2006-04-10
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c06f8e2

 ENH: fix re-run of cmake based on configured files that are
 done with copy if different and never change, 2006-04-11
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa415043

Then the fix that would have made it work was done in 2009 by
considering these outputs to be by-products that are expected
to exist but not necessarily be newer than the inputs:

 BUG: Fix OS X AppBundle/FW byproducts dependencies, 2009-02-06
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22827489

Then the original feature was finally restored in 2013:

 cmMakefile: Track configured files so we can regenerate them, 2013-06-18
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad502502

and later refined as you already mentioned.

The problem for VS and Xcode is that these "output" files may not
be newer than the inputs, so they cannot be simply listed as build
outputs of the rule to re-run CMake or it will run every time.
The Makefile generator solves this with the cmake_check_build_system
build target that runs every time and does custom analysis:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmake.cxx;hb=v3.0.0#l1971

Such always-run targets do not look clean to IDE builds.

-Brad