I got this warning:
DEBUG_INFORMATION_FORMAT should be set to dwarf-with-dsym for all configurations. This could also be a timing issue, make sure the Fabric run script build phase is the last build phase and no other scripts have moved the dSYM from the location Xcode generated it. Unable to process Project.app.dSYM at path /Users/user/Library/Developer/Xcode/DerivedData/Project-rgomisstclrabvudqmbwooyudhxw/Build/Products/Debug-iphoneos/Project.app.dSYM
Can anyone help me correct this?
Simply set the Debug Information Format under Build Settings to dwarf-with-dysym, both for Debug and Release modes.
A sample project with the settings highlighted in blue can be seen below:
Related
After updating to Xcode 10 there are some issues with initial project configurations. The steps look like this:
Generating some files using Sourcery
Linting with SwiftLint
Build
And configuration works like this:
And this was working fine in Xcode 9, but apparently, it's not working under Xcode 10 build system. The issue is if I download repository (.generated files are not a part of the repository). And hit build it will show me results like:
...
Using configuration file at '.sourcery.yml'
Scanning sources...
Found 239 types.
Loading templates...
Loaded 9 templates.
Generating code...
Finished.
Processing time 0.491948962211609 seconds
...
So sourcery works ok, then linting:
Linting 'FromResponse.generated.swift' (1/186)
Works fine as well as a process, but in the end, build will fail with:
error: Build input files cannot be found:
'/path/Generated/FromResponse.generated.swift',
...
So it's strange since a files are physically there and according to build settings file should be compiled later than generating them. How should I approach sourcery in build process then?
We are able to "fix" this in a similar way as this Github issue:
https://github.com/mac-cain13/R.swift/issues/438#issuecomment-416982928
We have to add each of the generated files by Sourcery to the output folder and it will get picked up by the Xcode correctly.
This relates to changes in the New Xcode Build System that has been enabled by default in Xcode 10. If a build phase creates files which are needed as an input to a later build phase then it needs to specify them explicitly in the Output Files or Output File List.
In your example the Sourcery build phase is generating Swift source file(s) which are needed as input to the Compile Sources phase.
However, the issue at this point is that after you specify the output files for Sourcery, the build phase doesn't re-run every time as it sees the output file is already there. So far I haven't worked out a useable solution to this part, beyond running tools like Sourcery and SwiftGen manually or keeping the generated files in Git so that they are always present.
I was having a similar problem with a buildphase calling mogenerator to build my data model classes. The approach given by #Yuchen should work.
#Andrew: To force always (re-)running this build phase, I add the line
touch .alwaysRun
as the last line in the shell command to run and mark the build phase "Input Files" to have $(SRCROOT)/.alwaysRun. That seems to do the trick.
I already finished my project, it works and runs perfectly on the simulator or in my own device. When I select to Archive the project to upload de build to Itunes Connect, I get all these compile errors
"Use of undeclared type MBProgressHUD"
"Use of unresolved identifier MPProgressHUD"
And so on..
NOTE: I'm using CocoaPods for this library
What solved it for me was adding import MBProgressHUD in the classes where I use this library, not only in the Bridge-Header.h
Navigate to your project build settings and find the “Swift Compiler – Code Generation” section (You may find it faster to type in “Swift Compiler” into the search box to narrow down the results)
Next to “Objective-C Bridging Header” you will need to add the name/path of your header file. If your file resides in your project’s root folder simply put the name of the header file there. Examples: “ProjectName/ProjectName-Bridging-Header.h” or simply “ProjectName-Bridging-Header.h”.
Refer this link http://www.learnswiftonline.com/getting-started/adding-swift-bridging-header/
Welcome to Cocoapods Hell (a.k.a. : where the magic ends), where one must dive into his project build settings and make sense of what went wrong...
It's very hard to answer to you, as any number of reasons might be causing that.
Do you use the same target for Build / Run & Archive ? It might be because your libPods.a isn't copied into your Archive target
Have you installed Pods using pod install , have you tried playing that command again. (yes, faced with magic going wrong, one can sometimes rely on magic to save him again)
'Build' and 'Archive' product often differ in the build configuration they use (Build most of the time uses 'debug' configuration, while Archive uses 'release' configuration... ). Check your Pods configuration files (debug/release) and make sure they both include your MBProgressHud. Also, in your Project 'Info', check which pods Xcode configuration files are selected for 'debug' and 'release'
Good luck !
(PS : as MBProgressHud is a single file, and one you can often change, another solution is to get rid of Cocoapods and just copy/paste it)
I've recently started getting this error:
2015-03-23 11:35:48.902 run[60036:1047011] Crashlytics.framework/run 1.3.14
2015-03-23 11:35:48.911 run[60036:1047011]
Crashlytics: dSYM Error
Unable to process <your app>.app.dSYM at path /path/to/<your app>.app.dSYM
Make sure your project build settings are generating a dSYM file. DEBUG_INFORMATION_FORMAT should be set to dwarf-with-dsym for all configurations. This could also be a timing issue, make sure the Crashlytics run script build phase is the last build phase and no other scripts have moved the dSYM from the location Xcode generated it.
Command /bin/sh failed with exit code 1
I tried this answer Unable to copy dSYM file into archive but all my Generate Debug Symbols are set to YES
Any further suggestions?
The below solution worked for me.
Go to build setting of your project, then Search for debug information format in build setting and search for "Debug information format" then set "Debug information format" to "DWARF with dSYM file"
and make sure Generate debug symbol in build setting is set to Yes.
Check for true "run script only when installing" on Run Script
Elaborating Bruno's response, if you already have a script phase that you need to run all the time, create a new dedicated phase in order to avoid conflicts.
I removed Fabric and Crashlytics and added them back again from the beginning just like I were to install it the first time around. It worked.
see also https://twittercommunity.com/t/how-to-reinstall-fabric-crashlytics/37890
"Build", "Archive" was successful. The archive had also passed validation.
However when I try to "Build for" => "Archiving", I hit the error Cordova/CDVViewController.h file not found.
I am experiencing this issue in version 2.4.0 of Cordova/Phonegap in Xcode 4.6
Most of the existing solutions given had already tried but failed.
Does anyone know how to resolve this issue?
I also met this problem, and finally find out why.Did you create a new Configuration by duplicating "Release" Configuration and set "Archive"'s Build Configuration to the new Configuration? Don't do it,just keep Build Configuration for "Release".Then everything will be OK.
Or you should keep your project and the CordovaLib project for the same configuration.
You can have multiple configurations, but you have to add the same configurations to the CordovaLib sub-project. See my answer here.
I have a series of projects within a workspace, and trying to use the following type of command to build them via the command line:
"Xcodebuild -project XXX"
or
"Xcodebuild -workspace XXX -scheme YYY"
Some of my projects build fine but others give strange errors, like "'XXX' for instance message does not declare a method with selector" or "ld: library not found for -lMyLibrary"
However all these projects build fine from within the XCode UI without issues.
Based on this is seems that the command line and UI builds are using a different toolset, but that seems like a very bad idea so I'm hoping I'm wrong about this. Or possibly there are just a few different build flags being set on the command line build.
I can try to troubleshoot the issues one by one but I'm hoping I can write a script which does the exact same type of build as the UI.
Any ideas?
Without including -configuration, xcodebuild is going to use the default configuration for each project. Generally that's Release. In Xcode, the Configuration you select will be applied to every project regardless of default.
Given your errors, your most likely problem is that you've used the build pane (why I hate the build pane for large projects), and you've made the classic mistake of applying some settings for Debug rather than all configurations.