MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007708CMakeCMakepublic2008-09-19 06:092010-12-14 18:45
Reporterjesperes 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformWindows/Visual Studio generatorOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0007708: Visual Studio generator does not check if it is being run from inside Visual Studio or from the command line
DescriptionWhen CMake generates Visual Studio projects, it attempts to interrupt/restart builds in progress. This is done in order to function correctly when CMake is being run from inside Visual Studio to update the project files. Without this behavior, the project files will not be reloaded until the build is complete (by the time is too late, and a new build will need to be started).

The problem with the implementation of this is that CMake does not properly detect if it is being run from inside Visual Studio, so if you have a Visual Studio instance running on a (completely separate) solution and run CMake from the command line, CMake will attempt to interrupt the running Visual Studio instance. This causes interactive dialogs, which have to be answered for CMake to be able to continue.

Thus, you need to close all Visual Studio instances if you want to run CMake from the command line, which is very annoying.

Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-09-19 06:09jesperesNew Issue
2008-09-19 10:22Bill HoffmanStatusnew => assigned
2008-09-19 10:22Bill HoffmanAssigned To => David Cole
2008-10-08 14:43David ColeNote Added: 0013771
2008-10-08 14:44David ColeStatusassigned => resolved
2008-10-08 14:44David ColeResolutionopen => unable to reproduce
2008-10-08 14:44David ColeNote Added: 0013772
2008-10-09 06:07jesperesStatusresolved => feedback
2008-10-09 06:07jesperesResolutionunable to reproduce => reopened
2008-10-09 06:07jesperesNote Added: 0013776
2008-10-09 10:39David ColeNote Added: 0013782
2008-10-10 03:45jesperesNote Added: 0013829
2008-10-10 08:41David ColeStatusfeedback => resolved
2008-10-10 08:41David ColeResolutionreopened => no change required
2008-10-10 08:41David ColeNote Added: 0013833
2010-12-14 18:45David ColeNote Added: 0024032
2010-12-14 18:45David ColeStatusresolved => closed

Notes
(0013771)
David Cole   
2008-10-08 14:43   
I do not think the "(completely separate) solution" part of your claim is true. (Sorry to be blunt, no ill will intended.)

You should not have to close all Visual Studio instances to avoid the dialogs, only the one with the top level solution file that CMake is regenerating.

CMake queries all running instances of Visual Studio and retrieves the open solution in each one. If the full path name of the solution file is the top level solution file that CMake is regenerating, then it interrupts the build for *that instance* of Visual Studio and invokes the macro to let the user choose what to do next. If the full path does not match the one being regenerated then CMake does not initiate any dialogs.

As far as detecting the difference between running CMake from the command line and running within Visual Studio... we could do that, but why should the behavior be different for the two...? If we do not invoke the macro on the matching instance of Visual Studio, then Visual Studio will prompt you multiple times the next time you activate it. It's a question of what you want your pain point to be: would you rather answer a single prompt (or 2 or 3 at most) during the cmake run or would you like to avoid that at the cost of having to wade through tens or hundreds or dialogs from Visual Studio...?

This feature was added and developed to reduce the number of dialogs and thereby make it feasible for a developer to leave VS open while running CMake. Prior to this feature, it was extremely painful/difficult to leave VS open while running CMake...

Can you give detailed instructions on how to reproduce this problem...? I have tried it with many Visual Studio instances running simultaneously and only the one with the regenerated .sln file presents any dialogs for me.

Thanks,
David
(0013772)
David Cole   
2008-10-08 14:44   
Please re-open with detailed instructions on how to reproduce if you still think there is something to fix after reading my note.....
(0013776)
jesperes   
2008-10-09 06:07   
Hm. I though I actually tested that, but apparently you're right.

Now I tried the following:

* Open VS on a given solution. No build, just open.
* Run CMake on that solution (from outside Visual Studio).
* CMake generates the solution.
* Visual Studio tries to start a new build.

(This isn't the original bug, but it is probably worth fixing. If there is no build in progress, CMake should only reload the projects, not start a build.)

Let me know if I should open a new bug for this instead.
(0013782)
David Cole   
2008-10-09 10:39   
Actually:
* Open VS on a given solution. No build, just open.
* Run CMake on that solution (from outside Visual Studio).
* CMake generates the solution.

***** CMake invokes a Visual Studio macro to prompt the user about project reloading. There are three options: (1) reload and start a new build via VS macro code, (2) reload only via VS macro code or (3) do nothing from VS macro and let VS do whatever it does in response to changed .sln and .vcproj files... (CMake 2.4 / VS default behavior...) *****

* Visual Studio tries to start a new build. (but only if the user clicked on "Yes" / choice number (1) in response to the prompt...)

If you do not want VS to do a build, then use the "No" or "Cancel" options to trigger reloading only.

Perhaps you object to the Yes/No/Cancel options or the phrasing of the text in the prompt, but the choice is yours about whether to start a new build or not. (Quite frequently, people will want to do a build immediately after CMake has regenerated the .sln file if they have it open already... even if they didn't have a build in progress prior to running CMake.)

If you have a suggestion for improving the text or choices, then please add some more feedback. It is implemented the way it is using a VB MessageBox call because it was simple to do. That's why it's a "Yes/No/Cancel" choice instead of "Reload & Build/Reload Only/Do Nothing" choice.

Clarifying text would be welcome...

Thanks!
(0013829)
jesperes   
2008-10-10 03:45   
It would be much clearer with a proper button labelling, yes. The majority of users won't even read the dialog, just click on yes to get the dialog out of the way. That's the way Windows has taught use to deal with dialogs: just press ok to get them out of the way. (Vista's UAC isn't helping here.)

But thanks, anyway. Now I know how to avoid triggering a rebuild.
(0013833)
David Cole   
2008-10-10 08:41   
Resolving for now. If anybody has a better idea for the text in the dialog, please add it here and re-open the issue. Or even better: a workable plan for making this a fully automatic process that does not require any dialogs in the first place...
(0024032)
David Cole   
2010-12-14 18:45   
Closing bugs that have been resolved for more than 3 months without any further updates.