xcode 4.2 build 4D177b doesn't show error in the issue navigator. When I build the app it pops up the build failed, but in the issue navigator the reason doesn't appear. I'm attaching a screenshot about the problem. How can I see the errors?
i've had issues where the workspace is invalid or corrupt due to pods needing update. if you've switched to a different source control branch recently and pods have changed, and your pods configuration expects a pod that hasn't been installed yet, sometimes it won't display the errors for your main target. try pod install to make sure the workspace, which is managed by cocoapods, is current.
Related
I am getting a strange error from sidekick cloud build since a few hours ago.
I was building the app successfully, but all of a sudden, it gives me the following error and even reversing the changes does not fix anything. I have even tried with a fully working version of my git repo.
[19-01-28 16:55:27.709] Build step started.
[19-01-28 16:55:37.465] (CLI) Unable to apply changes on device: a754d27bafb8bb273e444b9d6cefd370cd55f4d4. Error is: Build failed..
[19-01-28 16:55:37.469] Error detected during LiveSync on a754d27bafb8bb273e444b9d6cefd370cd55f4d4 for C:\Users\Afshar\Desktop\myapp. Error: Build failed.
I doesn't give me any more details about the issue.
I was wondering if anyone knows how to get more logs in cloud build or if this is a known issue?
Thanks
It happens with me as well for reasons unknown. I couldn't find any root cause, but I did notice one pattern. It usually happens when I am already running the app on an Android Emulator/Device.
When we execute tns run android --bundle, it listens for file changes after the first build and does some webpack incremental build thing afterwards, right?
At the same time, once Sidekick delivers a successful iOS build, it also starts listening for changes to do the webpack incremental builds on iOS.
So while we have these two LISTENERS active and we request for another iOS cloud build, before Sidekick communicates with the cloud, it modifies some files which the android listener detects and results in an incremental android build, which in turn modifies some other files, which the iOS listener detects, resulting in Sidekick trying to do the incremental iOS build but this time its stuck between giving you the incremental update and the new requested cloud build, so it throws you this LiveSync error.
Moral of the story: Try to request cloud builds, when these listeners are inactive.
I finally managed to solve it.
In case anyone else faces this issue, I tried the following command using a hint on this page and it solved the problem.
https://docs.nativescript.org/troubleshooting
tns platform remove ios
and then, I was able to build the project in sidekick.
I have a staging branch which builds successfully.
I create a branch "zendesk" and then I add
react-native-zendesk-support and react-native link it
Build fails.
Ok no problem, I close everything out (xcode and so forth) and switch back to staging branch.
Build fails and I see react-native-zendesk-support in my Libraries still.
I havne't touched the gitignore since react-native init... is the above expected behavior? Seems like a pretty poor default setup.
Attempting to build an ios project downloaded from the
build server, I get a link error complaining that the
"pods-develop" library was not found. There's also a
pods xcode project, but building it doesn't change the
outcome.
What information am I missing?
Do you have these hints in your Codename One propertie's build hint ?
ios.pods.sources=,https://github.com/CocoaPods/Specs.git
ios.objC=true
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'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.