In order to automize the build process when using a cross platform framework (FUSE). Unless I am wrong, I coudn't find any settings in FUSE to cover this cases so that's why I am trying to set them after FUSE builds and generates the xcode project files.
One of the issues I am facing right now is about the target device and the other one is adding an entry in the build phases.
STEP BY STEP
FUSE build generates the xcode project files including a new xcodeproj file everytime with a different FUSE-XCODE classes mapping so I cannot reuse it from one build to another
I can open the project in xcode IDE
Do some settings manually (target device and add a bundle resource)
Generate a build
Publish it to TestFlight
However, I am trying to make a command line build with the following steps:
FUSE build generates the xcode project files including a new xcodeproj file everytime with a different FUSE-XCODE classes mapping so I cannot reuse it from one build to another
Set the target device and the bundle resorce path by script
Build by xcode command line tools and generate the IPA file
Publish it to TestFlight
I already achieved to writhe the app name, version and build number by PlistBuddy using an script. However I didn't manage to do the same for the target device and adding a bundle resource.
About the device, I wanna set iPhone only:
About the Build Phases, I wanna add a Bundle Resource with the license of one library we use in the project. The license file is in a path belonging to the project.
Related
I am using Carthage dependency manager in my iOS project.
I have the Carthage/build folder in my repository to always have ready to go built frameworks when checking out the repo.
I am wondering what the bcsymbolmap files in the build folder are for. Quite a few of them are created with every carthage update.
Do I need to keep these files? Should I have them in my repository?
No, you don't need those files. If you set up Carthage properly, binary, .dsym and .bcsymbolmap files will be copied on build phase. When you archive the build for distributing using App Store, all needed files will be included in archive and after you upload the build to App Store you will be able to upload dsyms files anytime (to be able to decode your crash reports). If fact you don't need to store .dsyms and .bcsymbolmap files in your repository.
There is a good article explaining what is happening when the framework is being build (and what in fact Carthage scripts do) https://instabug.com/blog/ios-binary-framework/. Also it explains what for .bcsymbolmaps files used for - so Apple servers can rebuild your code using Bitcode and then you can desymbolicate your crash reports.
So, you don't need to keep those files. No need to store them in repository. The other reason not to store content of Build folder is that anyway your project can fail build with it on another machine with different environment. If you want to build your project with the same versions of dependencies - use Carthage bootstrap command instead of update.
P.S.
Also you can investigate what copy-frameworks command do:
https://github.com/Carthage/Carthage/blob/fc0166b4827736bac2c804fc928797f1a742c455/Source/carthage/CopyFrameworks.swift
If you use carthage build without the specification of a project, all
.bcsymbolmaps should be deleted, but if you use e.g. carthage build Alamofire it should just delete the corresponding .bcsymbolmap
From the discussion of a github issue. Looks like you do not need those files, since the default behaviour is to delete them when building a new build.
In general, you should not commit files generated during a local build into your repository, since builds can be device specific, and everyone cloning into or pulling from your repository should be able to perform a build themselves.
Bitcode Symbol Map(BCSymbolMap)
.bcsymbolmap is a textual file with debug information and which is generated for decoding stack trace. Solves same issues as .dSYM[About] but on more low level for and when Bitcode[About] is generated
It looks like:
BCSymbolMap Version: 2.0
__swift_FORCE_LOAD_$_swiftCompatibility50
__swift_FORCE_LOAD_$_swiftCompatibility51
__swift_FORCE_LOAD_$_swiftCompatibilityDynamicReplacements
_$sSo26SCNetworkReachabilityFlagsVMa
_$sSo24SCNetworkReachabilityRefaMa
...
Do I need to keep these files? Should I have them in my repository?
They are optional
For reasons beyond my control, I am using Xcode 3 and attempting to build a crude Audio Unit effect. While setting up the configuration for my project, I tried to set up a 'Copy Files' build phase in order to have the Component Manager be able to find my unit. When I dragged the Unit's component into the new Copy Files build phase and tried to to build the project, I am getting the follow error:
Check Dependencies: Product depends on itself. THis target might include it's own product.
I tried deleting the component file from my Copy Files build phase, and I was able to build the project successfully, however when I run auval -a in the terminal, the Component Manager does not find my effect unit.
How can i fix this?... is it even fixable in Xcode 3?
To accomplish build and install in one build invocation, you can either
a) create a separate target which defines the AU as a dependency and performs the copy (and any other post-build steps)
or b) set the INSTALL_PATH to the components directory and touch the AU as the last build step
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.
The tile basically says it all.
I'm developing a mac app which has the normal app target, but also has two more command-line tool targets whose products are copied to the app when building. I remember seeing somewhere that the "Skip install" was important in these cases, but I remember nothing of what I read, so this might be incorrect.
Anyway, I just wanted to know what this option affects.
I believe this only matters when you're developing for the App Store. If you archive your app target and this includes building other targets (command line tools, static libraries, ...), all the targets' products are copied into the archive, unless SKIP_INSTALL is set to YES.
You can verify this: Archive your application, find the archive in the Organizer, Option-Click --> "Show in Finder", go into the archive (Option-Click --> "Show Package Contents"), and in /Products you will find multiple files/folders. However, App Store builds only allow one product within the Products directory. Xcode warns you about this if you "Validate" your archived app in the Organizer:
When you set SKIP_INSTALL=NO (which is the default), the build target will be installed to $(DSTROOT)$(INSTALL_PATH) during the build phase. Setting SKIP_INSTALL=YES causes the target to be built but not installed.
Setting SKIP_INSTALL=YES can be useful for static archives (libsomething.a) that will be later linked into other targets or bundles that will be installed by another target's copy-files build phase.
Skip Install (SKIP_INSTALL)
In case with archive
xcodebuild archive SKIP_INSTALL=NO
NO - allows to put data into <some_path>/<some_name>.xcarchive/Products or install a framework in archive
I have a project which builds two targets, the main app and a tool.
How can I correctly include the tool in the app bundle? I have already navigated to target dependencies and added the tool; however when adding the built executable to the "Copy Bundle Resources" phase, I get a path to the builded product like:
.../.../awieuhfaowasldijfsalkdj/Build/Debug/tool
Is there any way to add the tool to the bundle dynamically, I mean without hardcoding such path? Ideally, I'd like to add the tool in a special folder (say "Tools") inside the "Resources" bundle folder, but I don't even know if that's possible.
Apart from this, is there something else I need to do in order to complete the process of adding it as a resource?
One simple way to avoid the weird path is to specify that the build location should be the one specified by the targets (by default build/Debug or build/Release under the project folder):
Open the Xcode preferences
Click on the Locations tab
Under Build Location, select Place build products in locations specified by targets