[CMake] Workflow of a collaborative project in Visual Studio+CMake

[Michael Hertling]

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
> <mike.jackson at bluequartz.net> 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