I installed OCMock via Cocoapods in my project. When I try to run the test project, it fails in the build stage as it is not able to find the libOCMock.a package. With so much hours spent on it, I found that libOCMock.a sits inside a folder called OCMock in the intermediate build folder (~/Library/Developer/Xcode/ProjectName-Hash/Build/Products/Debug-iphonesimulator/OCMock/libOCMock.a).
When I move the file manually one level down (~/Library/Developer/Xcode/ProjectName-Hash/Build/Products/Debug-iphonesimulator/libOCMock.a) everything works as expected.
Now do I add reference to this build path from Xcode or how do I tell OCMock to place the file one level down?
Please help me resolve this issue.
Related
Today I checked out a new copy of stable project from gitHub to my home computer using Xcode 6.1. After doing so, I see that many of the frameworks and libraries, including XCTest, are missing (shown in red). I have added Framework and Header Search Paths, but they are still not found.
To make things stranger, I can build the project to a simulator or device, but when I try to run an individual test, I get clang or missing file error for the libraries/frameworks shown in red.
As it turns out, the reason for my errors was that I had not run "Build for Testing" before trying to run the individual Unit Tests. As such, the proper library dependencies had not been generated.
I'm sure this is a dumb mistake on my part but I can't find the right answer.
I have a project that has a snapshot dependency on another project. For sake of discussion website is dependent on toolkit.
Monitoring the build folder:
c:\programs\Teamcity\buildagent\work
I see the toolkit get built and the folders all exist as expected:
c:\programs\teamcity\buildagent\work\toolkit
Then the website build kicks off and the folder above gets deleted before the website build starts.
This results in the website saying the reference couldn't be found. What setting am I missing?
Using TeamCity 7.1.2, working on getting it upgraded to 8.1 but it requires some internal evaluation first.
Don't think its a version issue. How do both of your builds know where to put the artefacts at . For ex teamcity normally builds stuff at c:\programs\teamcity\buildagent\work****\toolkit , not at c:\programs\teamcity\buildagent\work\toolkit ?
Also, if your targets are dependent upon each other across builds, (1) have you setup any artefact dependencies or (2) any process that does not read of a shared agent workspace ? or (3) forcing both builds to run from the same directory
See if both your builds are running on the same target "folder name". In case they are , deselect any option that "cleans up build targets" before they run.
Also, you might want to check your build files to see if they have any code to clean directories before they start to run
I've got a workspace containing an iOS app project, which is dependent on another framework project, also in the workspace. I ran into issues with Archive while building for distribution, where the resulting output was unusable for creating an .ipa. Googling turned up this solution, where you delete the Copy Headers phase from the framework project, and which worked for getting the Archive exported and submitted, but now when I go back to running the app project in debug, I'm failing builds due to missing header files from the framework project again. So, what is the proper way to configure everything so I can both archive and run in debug without having to go through all this nonsense? I mean really, I'd think this would be pretty typical.
I ended up replacing the previously deleted Copy Headers phase within the framework project, with a Copy Files phase, and that did the trick.
I am considering using CocoaPods on an existing iOS project.
However I got confused when I read the installation instructions, which say:
Make sure to always open the Xcode workspace instead of the project
file when building your project:
$ open App.xcworkspace
I have no idea what they want to tell me with that. I know there is a .xworkspace file within the .xcodeproj bundle.
But does that mean I can never again simple double click on my .xcodeproj file? Can I no longer open the project from the XCode recent items menu? And do I always need to open it from Terminal?
The concept of CocoaPods sounds interesting, but I don't want to mess with XCodes internal project structure...
A workspace is like a step up from a project. It can contain several projects. When you install Cocoapods on your project, it creates a workspace which contains your original project and a new Pods project which contains the code from the pods you are using.
It also creates dependencies between your project and the pods project (since your project needs the pods project to be built before you can build your own, it has to look for the headers, etc.). Because of this, if you subsequently open the project file instead of the workspace file, it will fail to build because it doesn't have the right information about the Pods.
The change doesn't really affect anything about the way you work - just double-click the workspace file instead of the project file, and the workspace will subsequently show up in your recent items list.
You don't need to open it from the terminal, that guide is just there because you would have installed the pods from the command line, so it is a convenience to then open the workspace file immediately from there.
I've setup cocoapods for my project and I've been doing development for quite some time without any issues. Recently I added a new Configuration for it called "Beta", duplicating the "Release" configuration. At the same time, I added a Scheme that would build targets using this configuration.
This new scheme would build everything without issues, but linking would fail with the (quite known it seems) message:
ld: library not found for -lPods
I know that issues that makes this error message come up have been discussed widely around the web, with different causes and conditions:
library not found for -lPods
https://github.com/CocoaPods/CocoaPods/issues/155
None of these fixes seem to apply here. What I can see by looking into the workspace folder, is that Cocoapods build products are put in Build/Products/Release-iphonesimulator instead of in Build/Products/Beta-iphonesimulator, even though the app itself is built rightly so into the latter. Moving all the *.a files into Build/Products/Beta-iphonesimulator makes running in the simulator work properly, but the next build is still put in the wrong location.
Edit
After some further investigations, the environment variable $BUILT_PRODUCTS_DIR is set correctly in the build phase for the app itself, but not when building cocoapods products.
What causes this and how can I fix this?
Ruled out issues
pod install has been run, multiple times
I'm working in the workspace, not in the project
The cocoapods configuration file in the new configuration is properly set
Build locations in the preferences seem fine
For the record, the issue has been solved. So, as I said, I use cocoapods, but my current setup is that a single podfile, and workspace is used for 3 projects that share some common libraries. As explained in this issue, cocoapods will only consider one project out of all those that are specified in the podfile, and it turns the one project (out of three) that it was using, didn't have the beta configuration, so it didn't feel the need to prepare for it. So when it was time to build the project with the beta configuration, cocoapods would be built for the release configuration, and put in some folder specific to release, so the beta project wouldn't be able to find it.
Fixing was a matter of creating the beta configuration for all projects present in the workspace, forcing cocoapods to prepare accordingly. Then, Xcode would be able to wire up everything appropriately.