I'm doing some refactoring (more than what CLion can do automatically) and making lots of changes. When I change a header file, it prompts a significant fraction of my project to rebuild, but I know the error messages will always come from the same spot (which unfortunately starts with "w").
Is there any way to control where CLion will start building so I don't have to wait 30s+ to get the next error message?
I've been typing make src/workflow.o in a console (I tried using the CLion console, but that doesn't make links from errors), but I'd rather have the direct links to the error location.
You can add another cmake target to build only the stuff you need.
See e.g. here:
https://www.jetbrains.com/help/clion/2016.1/creating-and-editing-run-debug-configurations.html?origin=old_help
I got a problem with some ressources. I got a simple .exe file, that is accessed by my application. So I saved the exe tool within my project folder and everything was simple. But now I want the exe to be embedded inside my application, to keep everything nice and clean.
I want my app to be a single file executable, that will deploy its dependencies and stuff on its own.
So read a little tutorial on stack: How to embed dll from "class project" into my project in vb.net
I got the .exe into my ressources and pasted the code into my ApplicationEvents.vb (don't kill me for CP ;) ). Next I tried to execute the whole thing, but nothing happend. By executing the application step by step (F8), I saw, that the AddHandler call is executed, but the Deploy Function gets never called.
Next I read a tutorial at MSDN:
https://msdn.microsoft.com/en-us/library/vstudio/e2c9s1d7%28v=vs.100%29.aspx
I tried to change the persitence mode of my ressource as described, but the Persistance option is disabled.
So what can I do to deploy my second .exe?
I want to try out Scintilla (in Cocoa), but XCode does not cooperate. I included the Scintilla framework at scite337/scintilla/cocoa/ScintillaFramework/build/Release/Scintilla.framework by right-clicking the target in XCode and selecting Add Existing Frameworks.. and then Add Others.... This seemed to work, suddenly the compiler seemed to find the files because the files produced some parser errors (so it has to get compiled, right?). But after I solved these errors, I got a knew one:
Framework not found Scintilla
Command /Developer/usr/bin/llvm-g++-4.2 failed with exit code 1
I did verify if the Target Membership of the framework was set to required and it was. I tried to set the header search path to the path of the framework as well, but that gave the same error. I have no idea how to proceed from here.
XCode 3.2.6, Mac OS X 10.6.8
I have a simple console application intended to exercise a library from a larger project. The console application is one target within an XCode project that also contains the library ( plus some other targets I don't care about right now). The console target references the library by listing it in the Build Phases "Target Dependencies" and "Link Binary with Libraries".
I can run the console program just fine from within XCode by clicking the "Run" button and examining the console output under "All Output".
However I get a load error if I try to run outside of XCode. I select the console application under "Products" in the project navigator, and then I locate the "Full Path" in the "Identity" section of the information panel. When I copy this path to a terminal window and run it, I get an error like:
dyld: Library not loaded:
#executable_path/../Frameworks/[LIBRARY].framework/Versions/A/[LIBRARY]
Referenced from: [THE PATH THAT I TYPED]
Reason: image not found
What should I do differently to get my console application to execute from the console?
(Note, in the "Copy Files" phase, I have tried leaving the "Subpath" blank and setting it to "#executable_path/../Frameworks" per this answer, which was about a cocoa app, but neither way has helped.)
As the commenters above explain, dyld is the dynamic loader and it is looking for my library at the path it printed. (When it says #executable_path, it means the location of the console application I'm actually trying to run.)
Looking at the compiled output from XCode, I see a folder hierarchy like this:
Debug/
MyProgram
Frameworks/[LIBRARY].framework/Versions/A/[LIBRARY]
For whatever reason, this structure does not match what the loader wants -- it is looking for the library at ../Frameworks rather than ./Frameworks.
Rather than messing with the environment variables used by the loader or trying to tweak the program itself, I just copied these files a new folder with the structure specified in the error message:
foo/
bin/MyProgram
Frameworks/[LIBRARY].framework/Versions/A/[LIBRARY]
I can now run foo/bin/MyProgram from the terminal without any problem.
I followed Apple's instructions to set up Unit Testing in my project. I followed the directions for making them dependent, so the tests run with every build of my main project. This works, and when my tests pass, the application runs; when they don't, I get build errors on the lines of the unit tests that failed.
I would like, however, to be able to step through my application code when the tests are failing, but can't get Xcode (3.2.5) configured properly. The project is a Mac project, not iOS.
I tried the instructions here and here, but execution never stopped at the breakpoints I set, neither in the the unit test code or in my application code. After following the first set of instructions, the breakpoints I set turned yellow with blue outlines, and I don't know what that meant, either. What do I need to do to step through my tests?
Update
I found another page attempting to solve this problem (here) by adding arguments and environment variables to my main executable, but again, those didn't cause execution to stop at my breakpoints. I also noticed that my test's (copious) log statements aren't showing up in my Debugger Console, either.
I also found out that the yellow breakpoints mean the code there can't be found at runtime. These are in my test case class, so that definitely seems to explain why those aren't firing.
I usually have no problem debugging my OCTest tests with Xcode 3.2, including halting at breakpoints.
The basic idea is to tell gdb to launch otest with your bundle as argument. You will do that by adding /Developer/Tools/otest as a custom executable to your Xcode project, then your OCTest bundle name as the sole argument (choose "Edit Active Executable otest" in the Project menu, and in the second tab add a line with Foo.octest in the top box to debug the Foo test).
Now if you hit the debug button it will start debugging your test bundle right now, and will stop at the declared breakpoints (if you hit build and debug it might not start if the test does not pass). Also note that you will maybe have to set an environment variable to YES to disable garbage collection (in the bottom box of the same "Arguments" tab), otest will tell you exactly which if you need.
If you did everything above and are still unable do step into your test code, this might either be because it is compiled with debug symbol generation turned off - check your debug build settings, but most likely because the test code is not recompiled at all. I say most likely, since your logs are not showing in the console, NSLog should write in the Xcode console. Clean your build and bin folders manually, sometimes when you change a path or a name you end up loading obsolete code. You might also want to check that the file has not jumped out of the test target (is the failing test in the same not-logging file ?).
I have a variant of what Hiedi Utley posted at http://hiediutley.wordpress.com/2011/03/08/xcode3-debugging-ios-unit-tests/. What I did not like about it is the duplication of unit test bundle targets, one that contained a Run Script phase to execute the unit tests after building, and another that did not run the unit tests. I had noticed in the Get Info pane for the Run Script phase the toggle "Run script only when installing" and thought that that would be a way to toggle between running the unit tests in normal mode and running them in the debugger.
As per Hiedi's instructions, create a new Executable item, say LogicTestsGDB. Configure it like so:
General Tab:
Path: Developer/usr/bin/otest (No leading /)
Path Type: Relative to Current SDK
Set the working directory to: Build Products directory
Arguments Tab:
Arguments: Your UnitTest Bundle (eg. LogicTests.octest)
Variables to be set in the environment
DYLD_LIBRARY_PATH ... : ${BUILD_PRODUCTS_DIR}:${DYLD_LIBRARY_PATH}
DYLD_FRAMEWORK_PATH . : ${SDKROOT}/Developer/Library/Frameworks
DYLD_ROOT_PATH ...... : ${SDKROOT}
IPHONE_SIMULATOR_ROOT : ${SDKROOT}
OBJC_DISABLE_GC : YES
DYLD_NEW_LOCAL_SHARED_REGIONS : YES
DYLD_NO_FIX_PREBINDING : YES
CFFIXED_USER_HOME : ${HOME}/Library/Application Support/iPhone Simulator/
Done. Now to debug your unit tests,
Expose the bundle's build phases and double-click on the Run Script phase.
Check the Run script only when installing option
Set the Active Target to be the unit test bundle (eg. LogicTests.octest).
Set the Active Executable to be the new executable created (eg. LogicTestsGDB)
Click Build and Debug
To run normally, executing unit tests as part of the build phase of the application:
Expose the bundle's build phases and double-click on the Run Script phase.
Uncheck the Run script only when installing option
Set the Active Target to be the application being built
Set the Active Executable to be the application being built
To automate the steps above, I created a simple AppleScript script that toggles between the two states:
property kApplicationName : "MyApp" -- name of the normal application to build
property kUnitTestName : "LogicTests" -- name of the bundle target to debug
property kUnitTestRunner : "LogicTestGDB" -- name of the executable to use when debugging the unit test bundle
tell application "Xcode"
tell the active project document
set theTarget to first target whose name is kUnitTestName
set thePhase to first run script phase of theTarget
if name of active target is kApplicationName then
set active target to theTarget
set theExecutable to first executable whose name is kUnitTestRunner
set active executable to theExecutable
set run only when installing of thePhase to true
else
set theTarget to first target whose name is kApplicationName
set active target to theTarget
set theExecutable to first executable whose name is kApplicationName
set active executable to theExecutable
set run only when installing of thePhase to false
end if
return "Targeting " & (name of active executable)
end tell
end tell
I also tried the solutions in the links you provided with, but none worked for me, too. But then I found this one: http://hiediutley.wordpress.com/2011/03/08/xcode3-debugging-ios-unit-tests/ -- it works like a charm :) Fresh stuff, too.
develop your unit tests so they wrap a program which resides in a project which has a target, then just open the dependent project and work in it. this would likely be a project with a library and an executable which calls through the library (2 targets). then you can just open the project and debug, while your unit tests in the dependency would then call through this library. this is a more modular approach.
good luck
The only thing that ended up working for me was upgrading to Xcode 4. It integrates beautifully. There was a little bit of pain in moving over to it, but now that it's over with, the integration is great. I'm fully able to step through my tests and application code.