|
Notes |
|
|
(0015718)
|
|
Alex Neundorf
|
|
2009-03-17 17:16
|
|
I still think this would be a good idea, but I'm not completely sure what it should do.
So, with the Makefile generators, it should probably run make.
With e.g. the CodeBlocks generator, which is also Makefile-based, should it run make or start CodeBlocks with the generated project ? (probably the second)
For the Xcode and Visual Studio generators it should probably start the IDE instead of executing the builtool (e.g. xcode-build or what the name was).
What do you think ?
We can add code to the cmake scripts so that they search e.g. for the codeblocks executable when the codeblocks generator is used, so that this information would be available to cmake-gui.
Alex |
|
|
|
(0015719)
|
|
Clinton Stimpson
|
|
2009-03-17 18:20
|
|
I'm not sure what it should do either.
Bug 0008664 might overlap with this.
It seems the intent is a quick way to start compiling after cmake has created the build files. If that is it, then it seems there are more way to do this.
Also, if one should be able to close cmake-gui and still have the IDE or terminal alive, then I don't think it can be a child process of cmake-gui. |
|
|
|
(0015728)
|
|
Alex Neundorf
|
|
2009-03-18 18:41
|
|
Yes, it's more or less the same as 0008664.
Alex |
|
|
|
(0015748)
|
|
Philip Lowman
|
|
2009-03-21 20:31
|
|
I suggest calling the button "Open". Please do not make the default behavior to start the build upon the IDE being opened although this might be possible as a user option for certain IDEs that support it.
For Makefile based generators that do not use an IDE the Open button could spawn a terminal in the build directory. |
|
|
|
(0019141)
|
|
Michael Wild
|
|
2010-01-14 14:50
|
|
I think the user should have all of these options:
- Open the project in the IDE corresponding to the generator (if available/applicable/implementable). This is what 0008664 is about.
- Have a drop-down menu to select the build configuration for multi-configuration generators. The same drop-down could be used to select the build target (like in Xcode)
- Have buttons (possibly a dropdown-button, also like in Xcode) to build, clean and install the project. If it's a dropdown-button the default action could change from "build" to "install" after a successful build.
- Don't need a button for this, but it would be nice to have a menu-entry to open the source and binary directories. |
|
|
|
(0019160)
|
|
Michael Wild
|
|
2010-01-18 04:42
|
|
The attached patch
* adds menu-entries/buttons to open source and binary directories in file
browser. Not too sure about the button-icons (grabbed it from tango, actually is an overlay to indicate symlinks)
* replaces "Configure" and "Generate" buttons with a single button with a
delayed popup-menu, alowing one to configure, generate, build, install
and clean the project.
* reads the cache to find CMAKE_CONFIGURATION_TYPES and offer the
available build types in the menu and a combo-box next to the "action"
button. Requires, however, that all available build types are stored
in the cache.
TODO:
* For IDE-projects add a button to open the project file.
* Somehow capture stdout/stderr when building/installing/cleaning
and display in output widget.
* Parse output from Makefile-builds and drive progress-bar instead
of using the generic "busy" display. |
|
|
|
(0019180)
|
|
Clinton Stimpson
|
|
2010-01-18 22:06
|
|
A few comments:
cmSystemTools has a way to get the stdout when building, installing and cleaning. QCMake doesn't install a message handler for that.
We should have a way to interrupt the build, install and clean. I'm not sure if sending SIGINT to a child process is supported with kwsys, or at least getting the pid for the child process.
Hitting the build project, while it is building, actually queues another build after the first is done. I guess enabling the "stop" would get around that.
Going back to configure doesn't remove the combo box that shows up (for selecting build config) after a generate.
It gives the option of installing even if the build failed.
Did you have thoughts on progress display when not using makefiles?
Did you have plans to do a bit more work on this to fix issues? Or were you hoping someone else would? |
|
|
|
(0019187)
|
|
Michael Wild
|
|
2010-01-19 01:20
|
|
I tried having a look at cmSystemTools and kwsys, but couldn't figure out how to do things. IMHO the whole thing is only useful if stdout/stderr can be captured.
Yes, aborting would also be required, but again, I need some help here how to do this with cmSystemTools.
Indeed, I never thought of hitting the disabled button... ;-) Will fix ASAP, should be pretty easy to do. I didn't want to enable the "stop" button, because currently I don't know how to do this as mentioned above.
Should the combo-box be removed? After first hitting "configure", the project IS configured, and the available configurations presumably don't change after a generate/build/install.
Will fix the issue with the enabled install-button after a build-failure. Didn't think of that too...
About the progress for non-makefile generators, I have no idea whatsoever. AFAIK this information is not available to CMake, but I might be wrong.
Will get started on the easy issues (not-really disabled build-button and enabled install-button after build-failure). For the other issues I probably need some help/guidance from somebody knowing cmSystemTools/kwsys. |
|
|
|
(0019188)
|
|
Michael Wild
|
2010-01-19 03:30
(edited on: 2010-01-19 03:31) |
|
Attached a new version of the patch with the following changes:
* Prevent the "action"-button from triggering if disabled
* If any of the actions fails, go back to the configure-step
* Also disable the "Active Configuration" menu. Disable both, the menu and the combo-box, when an action is running. On Qt-Cocoa 4.5.3 work around QTBUG-5313.
Thanks for the feedback, Clinton!
|
|
|
|
(0019225)
|
|
Clinton Stimpson
|
|
2010-01-20 14:58
|
|
To interrupt the build/clean/install (maybe add package too?), it can be spawned off in a separate process. It might work using kwsysProcess to run "cmake --build" for example. But I don't see how to get a message to the thread QCMake is on to interrupt it. QProcess should work though.
To redirect stdout from cmake, one could add a call to cmSystemTool::SetStdoutCallback in QCMake.cxx much like we do for errors, but that only works if cmSystemTools is used to run these commands.
For the QProcess/kwsysProcess approach, they have their own methods for reading the stdout of the child process. |
|
|
|
(0019238)
|
|
Michael Wild
|
|
2010-01-21 08:19
|
|
I'd prefer not to fork "cmake --build", since there is cmake::Build(...).
Concerning capturing of the output, having traced function calls and studied the code a bit more, there actually is cmSystemTools::SetStdoutCallback(...) allowing one to install a callback function which receives chunks of output from the child process.
Will check out whether that works as expected.
Stopping the child process will need some further investigation though. Perhaps the above-mentioned call-back function could be used to check back whether the process should be stopped, and then set a flag in the cmSystemTools class which causes it to kill the child. But this will require changes to the cmSystemTools class. |
|
|
|
(0019263)
|
|
Michael Wild
|
|
2010-01-22 04:28
|
|
Added an updated patch (-v3) which (in addition to above mentioned capabilities)
* Captures build/install/clean output, displays it in the message window
and parses progress for "Unix Makefiles" generators, driving the
progress indicator.
* Enables the "stop" action for the build/install/clean step.
For this a new callback function to stop cmSystemTools::RunSingleCommand
had to be added to cmSystemTools. For consistency it
would be nice to implement this also for cmSystemTools::RunCommand,
but for the functionality implemented here it is not necessary and
since the UNIX implementation uses popen this can't be done easily
(popen doesn't return the child process id).
On the TODO list are still the button to open the project file for IDE-projects and a way to infer the progress from non-Makefile generators. |
|
|
|
(0041478)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
0001-ENH-Improve-cmake-gui-v1.patch (35,921) 2010-01-18 04:39