[CMake] Visual Studio 2013, increamental builds, intermediate directories and long target names

[david_bjornbak at keysight.com]

I appreciate the feedback on this issue.

Deterministically generating a GUID sounds like a real solution.

++David->Bjornbak;

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Monday, June 01, 2015 12:09 PM
To: BJORNBAK,DAVID (K-Sonoma,ex1)
Cc: Dan Kegel; cmake; Bill Hoffman
Subject: Re: [CMake] Visual Studio 2013, increamental builds, intermediate directories and long target names

On 05/31/2015 12:43 PM, Dan Kegel wrote:
> Did you try the workaround suggested in the first link you gave, i.e.
> 
> set( RatherLongLibraryName_GUID_CMAKE <generated GUID> CACHE INTERNAL 
> "remove this and Visual Studio will mess up incremental builds")
> 
> On Sun, May 31, 2015 at 9:04 AM, david_bjornbak at keysight.com wrote:
>> VS 2013 with cmake working with long target names.

For reference, the length of the target name changes the behavior of VS but not of CMake.

>> http://stackoverflow.com/questions/28959488/how-to-enable-incremental
>> -builds-for-vs-2013-with-cmake-and-long-target-names

>From that link:

 "solution is regenerated each build after the CMake cache
  has been cleared"

Clearing the cache causes CMake's storage of the GUID used for each target to be reset, so it generates a new one the next time around.  The above-mentioned workaround tells CMake to use a fixed GUID so it stays the same every time.  Note that this workaround sets an internal/undocumented variable so it is not guaranteed to work in the future.

Currently CMake was not designed to guarantee any behavior for an incremental build when CMakeCache.txt and/or CMakeFiles/ is removed without also removing other build outputs.  Still, we may be able to address this particular case.

If I get a chance I'll look at whether CMake can deterministically generate a GUID from a hash of the build tree and target names or something like that.

-Brad