| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0007708 | CMake | CMake | public | 2008-09-19 06:09 | 2010-12-14 18:45 | ||||
| Reporter | jesperes | ||||||||
| Assigned To | David Cole | ||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
| Status | closed | Resolution | no change required | ||||||
| Platform | Windows/Visual Studio generator | OS | OS Version | ||||||
| Product Version | CMake-2-6 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0007708: Visual Studio generator does not check if it is being run from inside Visual Studio or from the command line | ||||||||
| Description | When 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0013771) David Cole (manager) 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 (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (manager) 2010-12-14 18:45 |
Closing bugs that have been resolved for more than 3 months without any further updates. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2008-09-19 06:09 | jesperes | New Issue | |
| 2008-09-19 10:22 | Bill Hoffman | Status | new => assigned |
| 2008-09-19 10:22 | Bill Hoffman | Assigned To | => David Cole |
| 2008-10-08 14:43 | David Cole | Note Added: 0013771 | |
| 2008-10-08 14:44 | David Cole | Status | assigned => resolved |
| 2008-10-08 14:44 | David Cole | Resolution | open => unable to reproduce |
| 2008-10-08 14:44 | David Cole | Note Added: 0013772 | |
| 2008-10-09 06:07 | jesperes | Status | resolved => feedback |
| 2008-10-09 06:07 | jesperes | Resolution | unable to reproduce => reopened |
| 2008-10-09 06:07 | jesperes | Note Added: 0013776 | |
| 2008-10-09 10:39 | David Cole | Note Added: 0013782 | |
| 2008-10-10 03:45 | jesperes | Note Added: 0013829 | |
| 2008-10-10 08:41 | David Cole | Status | feedback => resolved |
| 2008-10-10 08:41 | David Cole | Resolution | reopened => no change required |
| 2008-10-10 08:41 | David Cole | Note Added: 0013833 | |
| 2010-12-14 18:45 | David Cole | Note Added: 0024032 | |
| 2010-12-14 18:45 | David Cole | Status | resolved => closed |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |