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, [email protected] 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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
