Once I click on the "build" button I don't seem to have a way of stopping the build progress. I have a project with several thousand source files and if I find out something is wrong, my only solution seems to be to kill or quit CLion and start over, and of course wait around 10 minutes for it to load the project again. Is there a magic hot key to abort the build?
There's an interrupt button right to the progress indicator in the status bar.
If you don't want to use clion to create cmake-build-debug directory and you don't want it to compile your code by clion everytime you change and start clion, you can remove the cmake profile from
File->Setting->Build,Execution,Deployment->CMake
And use (-) symbol to remove the profile.
Related
I left VB6 and programming all together years ago, so pardon since I'm still dusting off what I remember.
I have an old program made for a friend in VB6 that he still runs in Windows Vista. He tried to update a label in the program and in trying to do the update, he has overwritten the project file where I used to see all forms and modules together.
Is there a way I can recover or recreate the project file as it was? All project files and modules are there, but when I open the VB6 project it shows only one form, that I can't compile or execute because it shows a "source not found"
I tried to go back to an old version of the project file with file recovery software but I couldn't find it.
Other way?
Practical steps to recover:
First and foremost: Back up what you have. Do this now.
Second, and only after the first, check (again) to see if you have a previous backup. Yes, this may seem pedantic, but, really, it's worth looking. Was that the only copy? Once you do all of this, consider creating a git repo for your code.
Third, in your empty project, simply right-click in the project explorer (Ctrl + R), and click "Add >" and then "Add Files...". Then, in the file input box, scroll down to the first file, hold down shift, and keep pressing the down arrow and all the files you want. Click "Open". Repeat if need be.
Finally, you need to re-add any dependencies. One way is simply to try to run the program with full compile (Ctrl + F5 or File | Run With Full Compile in the menus). If everything starts up, consider yourself fortunate. If not, you'll have to see each one that fails and add them back. This could be tedius, but just go through them one by one. In the Project menu, both "Components" and "References" can be gone through. Do this until the program successfully starts with full compile.
At this point, consider a making a backup. ;)
I am trying out GoLand and hear that the debugger is supposedly awesome, but I can’t find any documentation explaining how to set it up (GoLand is in preview stage, so that’s not really surprising). My use case: I am writing a REST API to which I send requests using curl. Could someone please tell me, step by step, how to get started with the debugger ?
[edit 1] (moved from comment) When I click Run/Debug (or Run/Run), a window is displayed, asking me to edit configurations. I am given a choice of several kinds of configurations, I try to choose "Go application" but the Debug button never is grayed and I can't get it to become clickable. I am very new to GoLand, I may be missing something obvious, but I can’t find whatever settings are missing.
[edit 2] It turns out that my workspace did not conform to the Go specifications : my code was not in a directory named src. Now that it is the case, I can click Run/Debug and GoLand seems to be doing the right thing, except it doesn’t stop at breakpoints or otherwise behave like a debugger, my code just runs.
[edit 3] Tried again, and it works. Sort of. I have no idea why it works now, even though it didn’t previously and I didn’t change anything. Now breakpoints work at some lines, and not at others. Or the debugger stops at the breakpoint, but I wait forever for the list of variables to be loaded. Well, it is a preview, after all...
[edit 4] I was notified just today that a new version of GoLand was available. I upgraded, and debugging is working well for me now.
GoLand will not enable the debug action (although run is available) if your code does not reside inside src. There is no warning about this, so it might be really a pain to solve this.
Additionally, depending on your project’s structure it might be possible, that debugging is still not working. In that case, it might help to remove all run configurations and create a new one. There’s is a bug report about this behavior.
PS: Although the OP mentions the first part in an edit of the question, but it think it’s worth mentioning in an answer.
Things changed in goland since #Jamillo Santos added his reply.
To start with, there's no more "Go Application".
The easiest way is to locate the file containing the main() function.
There should be a small triangle pointing to it, like in the attached screenshot:
When you click on the small green triangle, you get a menu with Run/Debug options.
Each will create a go build configuration.
You can edit that go build configuration and add the program arguments for your application.
For example, if your program have a command line argument of --arg=value you can add it like this:
I was facing this same issue and I solved by using the "Go Application" configuration (at the Run/Debug Configurations window), instead of the "Go Single File" configuration.
So, go to the upper right corner of the Gogland and "Edit configurations".
Then, add a new configuration using the "Go Application" profile.
After saving, you should be able to debug your code. o/
An easy way to enable this configuration is to use the #user1793301 method and right click on the file you want to run and select "Debug 'go run .go'".
POSSIBLE EXPLANATION
NOTICE: I did not look any further details about it.
Fact: "Go Application" configuration does build the binary executable before running it.
Fact: I could see looking at the console output (inside of the Goglang) is that the IDE uses the DLV as debugging tool.
Fact: I found a dlv debug at the DLV documentation and it seems to compile and debug the code.
Hypothesis: The guys from Jetbrains did not implement it. Or at least not YET.
On version 2019.1.1 there's no more Go Application. Use Go Build instead. Here I am debugging a single script file, but if you have a server app or smth, just point to the main app file:
Notice that in the Files field you have to specify the actual file path. You can put more files (if you want to have more starting points) by separating them with a pipe |. For each file you want to be able to debug, you need to specify the full path.
Again, if you are debugging a server app or something else, that has a single starting point, you only need the startup file specified in the config. :)
I had this exact problem.
Deleted and recreated the Debug run configuration. Debugging then worked perfectly.
I followed the following procedure to start my golang server in debug mode. (You might want to use some other method than creating a makefile for starting your server maybe)
Create a makefile
Define your server/worker startup command in the file
Run it by creating a new configuration for Makefile
Go to Run -> Attach to process -> choose your running server
This will attach the debugger to your process.
Note:
You might need to restart your server for this to work.
The IDE will ask you to install gops, do install it. Without installing gops you won't see any running process.
I right click on project (main.go inside) and choose "Debug ..." and it work
I have an Xcode 4 workspace with several projects. Everything builds perfectly and works as expected, only Xcode recompiles files too often. If I hit the Build button, wait for the compilation to succeed and then hit the button again, shouldn’t that be essentialy a no-op, since no files have changed? Because my Xcode recompiles a big part of the project again. Even when I build and then immediately hit the Play button, I have to stare at the building process again. Is that neccessary, is it expected behaviour?
Shot in the dark, but do you have external xcode projects linked? XCode may be recompiling because it doesn't know the state of those projects.
Either way, you can always Run Without Building ^⌘R (control + command + r)
Are you executing custom scripts that change files before compilation? This will result that xcode will recompile all touched files even though maybe nothing changed.
You can turn this off by enabling a checkmark in the run script build phase. This will execute the script only on installation of the app.
The image below shows the actual checkmark.
Can anybody explain to me the cause of the following message, perhaps along with suggestions as to how to fix it?
I'm running XCode under root using sudo <path to xcode because I need to debug a daemon that has to run as root.
I've done this several times successfully, but now when I try to open the project in Xcode I get the following message from XCode:
2009-06-09 10:04:25.521 Xcode[434:a0b] index is corrupt, will rebuild
Segmentation fault
Other projects open fine, and this project opens fine in a non-root instance of Xcode.
I've tried restarting the computer and deleting all of root's pbxuser files etc from inside the project.
Also, if now I go in and try to rebuild the index in Xcode running under my own user I get the following assertion failure. If I hit continue Xcode crashes.
ASSERTION FAILURE in /SourceCache/DevToolsBase/DevToolsBase-1114/pbxindex/PBXProjectIndex.m:305
Details: NULL symbol vector with value 278024
Function: _symbolKeyForValue
The solution to this is to completely remove Xcode's current index, which is in the build folder of the project. So delete the entire build folder and then reopen the project and it should be fixed.
For those still looking for the answer to this issue, it might be easier to follow these instructions from Andrew Pontious:
Open Xcode, go to its preferences,
then Code Sense, and uncheck "Enable
indexing for all projects". Press the
Apply button in the prefs window.
Once that's turned off, open your
project. It shouldn't crash anymore.
Then, go back to the preferences, and
turn indexing back on. (Click Apply.)
Again, it shouldn't crash, but it
should completely reindex your
project.
Re-enabling indexing made Xcode (3.1.3) crash again for my project, so I have left it disabled.
i have a XCode project (my main xcode project which has its executable). It has dependencies on a few other projects (under the Project tab in Detail View, there are a few other xcode project that it depends on).
My question is how can I setup breakpoint in the code of the dependent project?
I tried this, but this does not work
1. open my main xcode project
2. double click one of the dependent xcode project
3. in the source directory, find the file I want to break and add a breakpoint (by click at the side of the border of the editor, a blue 'bookmark thing' shows up)
4. Go back to 'Build and Go', my application does run but it never breaks at the break point I set in #3.
Can someone please help me? I have spent days on this, I can't figure it why.
Thank you.
1) Add the breakpoint in your project
2) Go into breakpoints view in xcode (top left besides project navigator) The view's icon is like a breakpoint icon
3) Right click on the required breakpoint and select "Move to" -> "User"
If the breakpoint is under "User" project, then it is accessible by all projects.
Whenever I've had trouble setting breakpoints with the Xcode GUI, I've managed to do it with the debugger command line (that is to say, the "lldb" prompt in the output window). For example, to set a breakpoint in source file "client.m" at line 42, type:
(lldb) b client.m:42
Besides being a fix for this particular problem, debugging on the command-line offers far more flexibility and automatability than any GUI could. A good place to start would be the LLDB tutorial. (Full disclosure: I'm a longtime fan of unix and gdb, so there's some bias here).
Of course, as others have mentioned, make sure the library/dependant project is compiled with debug symbols. Hope this helps; good luck.
I'll echo Jon-Eric here and also add that if you habitually run your project with Cmd+Enter, you should consider switching to Cmd+Y to enable gdb each time.
a few things here...(some obvious some not)
1) be sure that the dependant project is compiled with debug symbols (i'm assuming its a library)
2) be sure that your active executable is linking against the debug version of your dependent library
3) set a breakpoint in your main project just before calling into the entry point of your lib, and set a bp on the entry-point of the lib... (in addition to the real breakpoint you are looking to hit...)
I have found that the best way to debug a library is to open the lib project and set the active executable to be the main project, and then just hit "build and debug" directly from the library project.
I hope this helps, good luck, and have fun!
I've had similar problems with Xcode. The solution for me is to make sure that there is also a breakpoint in the main project that gets hit (as Kent mentions in his third point). I don't understand why this works though.
You should also only set breakpoints in a project when you've got it open. If you don't, they can start misbehaving: still stopping the flow of execution after you've disabled or deleted them, or not working when you think they're enabled.
Make sure you select 'Build and Debug' (for step #4). 'Go' sometimes means 'Run' (breakpoints disabled) and sometimes means 'Debug' (breakpoints enabled).
Also, make sure that you leave the dependent project open while you debug the main project.
In addition to kent reply about debug symbols, check COPY_PHASE_STRIP value in the build settings of the main project, and be sure it is set to NO in debug.