On 11/12/2011 01:39 PM, David Cole wrote: > For reference, the bug Mike refers to is this one: > > http://public.kitware.com/Bug/view.php?id=11258 > > I always use the manual technique of shutting down VS, running CMake, > and then re-opening VS. It's really not that bad, once you get used to > it. > > > David C.
Is it possibly an alternative to use "cmake --build" within an already configured build tree, provided the VS IDE is not strictly necessary? E.g., when porting a project from *nix to Windows, I usually open the VS shell, run CMake on the project's source tree from within a build directory and finally "cmake --build .". For last-minute changes, I use the editor of my choice and invoke "cmake --build ." again. With Makefiles on *nix, this approach works as expected, but with VS, I noticed the following issue: The project is correctly rebuilt after a change in a source file, but a change in a CMakeLists.txt file only results in a regeneration of the solution and project files *without* recompiling or relinking anything, i.e. it is solely the ZERO_CHECK project which is rebuilt. In order to rebuild the actual targets, I need to specify the "--clean-first" option to "cmake --build .". It seems as if a changed VS project file doesn't make VS recompile the affected source files, even if this is clearly necessary, e.g. due to changed preprocessor definitions. Is this behavior intended or VS-immanent, or should it be taken for buggy? Perhaps, a VS expert could shed some light on this matter; it'd be greatly appreciated. Regards, Michael > On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson > <[email protected]> wrote: >> It is worse and better. >> >> 1: CMake will generate the VS projects and solutions every time it needs to >> run. DO NOT EDIT the generated VS projects and solutions. Add the >> requirements to the CMake files. >> >> 2: If you are on VS2007/VS2008 and you do a "git pull" and then switch to VS >> and click build a cmake check is run FIRST. If anything is different the new >> solution and project files are generated and then the build continues. You >> will get a dialog asking if you want to reload all of the projects. Things >> are pretty nice. >> >> 3: If you are on VS2010 there is now a long standing bug that seems to have >> no solution where you basically have to do the following: >> Close the VS solution >> git pull >> run cmake to regenerate the solution and projects >> Open the Solution and Compile. >> >> Yep. Sucks. Purchased VS2010 last year and have yet to use it because of >> that bug. If we (the cmake community**) were to actually figure out how to >> solve the problem then VS2010 would be as seamless as VS2008. Here is hoping >> for the future. >> >> ** I have kept track of the bug. Kitware and others have put a lot of time >> into trying to fix the bug. It just seams to be one of those elusive fixes >> that there just may not be a solution to. >> -- >> Mike Jackson <www.bluequartz.net> >> >> On Nov 11, 2011, at 5:30 PM, David Doria wrote: >> >>> I typically work in KDevelop which has CMake support, so if another >>> developer pushes some new files and changes to the CMakeLists.txt of >>> my project, I simply 'git pull' the project and then click "Build" and >>> it knows exactly what to do - it runs CMake and then builds the >>> project. >>> >>> However, when working with Visual Studio, do I have to 'git pull', >>> then go open cmake-gui from the VS2010E terminal, re-configure and >>> re-generate the project, then reimport the VS2010E project, then >>> build? This seems horribly awkward. And the reverse appears to have >>> the same problem - if working inside VS I add a file to the VS >>> project, how do I 'export' this addition back to the git repo? >>> >>> Thanks, >>> >>> David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
