The icon in Xcode says "Build and Run". How do I change it to "Build and Debug"
I read that if you use "Build and Run" then it does extra work to optimize the code.
"I read that if you use "Build and Run" then it does extra work to optimize the code."
No - this is completely wrong - Release builds typically have optimisation enabled and Debug builds don't. This has nothing to do with how you run the program (i.e. Run vs Debug), it just depends on which configuration you are building.
Option-click the Build and Run button and you'll have the Build and Debug button until you option-click again to change it back to Build and Run.
You need to add breakpoints to your code to change the icon for debugging
Related
I loaded a Maven project in IDEA 2018.1.5. I configured an "Application" run/debug configuration to run it.
I could have sworn that in the past, IDEA would automatically invoke "Build Project" before Run/Debug if any source files had changed. Then something happened recently, and it no longer does. Now, every time I run/debug the project, it runs the compiled code even if it's stale (ignoring changes I made to the source-code).
I checked Settings -> Compiler -> "Build project automatically" is on. I think I tried disabling it at one point and I did not notice a difference. What other setting could be causing this behavior?
Edit run configurations, select the good one, make sure "Build" is present in the "Before launch" at the bottom of the dialog box.
I'm using Xcode 4.3.3 and have tried to configure my (one and only) scheme so that "Run" will build a release version (i.e. non-debug version) of my app for testing on the simulator and my device.
I attempt to do this as follows:
In the scheme editor window I highlight "Run" in the left column, and then for "Build Configuration" I select "Release". (I also set the debugger to "None").
However, when I build & run the application, the log navigator displays "Build MyApp1" followed by "Debug MyApp1".
My questions are: should this message displayed by the log navigator say "Release MyApp1" to reflect the build type I selected in the scheme editor? Or does "Debug" in this message just always get displayed when you choose "Run"? Is it in fact running the debug or release version?
Thanks,
BH
Go TO Edit Scheme, choose the type that you want.
In order to test whether your compiled file is running a debug version, you can try something like this in your home controller's viewWillAppear:
#ifdef DEBUG
NSLog(#"running debug version");
#else
NSLog(#"running another version");
#endif
If you're not getting the result you're expecting, you can try setting the release flag to YES and debug flag to NO in build settings.
I hope this helps :-)
This doesn't seem to be going away.
Here's the problem - I choose Product > Profile in XCode. Instruments opens, asks what I'd like to track, I choose Time Profiler, and it opens, but won't let me start the task, stating the error
Target failed to run: Remote exception encountered: 'Failed to get task for pid 1461'".
The 1461 changes to something different every time.
In Xcode, I have my Profile scheme's build configuration set to "Debug". In the target's build settings I have Code Signing Identity set to iPhone Developer for everything right now. In the project's build settings I have the same.
How can I get rid of this error, so I can test my app?
EDIT: Turns out I had to delete the app from my phone, and I did Product > Clean along with restarting xcode too.
The solution for me was to make sure that my Profile scheme was using the "debug" and not "release" build configuration.
In Xcode 4 select Product/Edit Scheme from the top menu then click on the "profile" button on the left. On the "info" pane you will see a setting for Build Configuration- set that to "debug"
Thanks,
For others coming by this question:
For me, the solution from this question worked:
The solution for me was to make sure that my Profile scheme was using the "debug" and not "release" build configuration.
In Xcode 4 select Product/Edit Scheme from the top menu then click on the "profile" button on the left. On the "info" pane you will see a setting for Build Configuration- set that to "debug"
If I just build my Xcode 4 project (using the cmd-B) command, which target is built?
I'm having trouble understanding the new scheme setup. When I look at the currently selected scheme, under the "Build" tab, all my different build types are checked (ie: Analyze, Test, Run, Profile, Archive). However, when I build, it seems like only "Run" is built. And for the *.app file that is produced, is this built using the "Build Configuration" set under the "Run" tab?
Thanks!
Sunny
Whichever target that is in selection next to your Run, Stop button in your Xcode.
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.