-
Notifications
You must be signed in to change notification settings - Fork 50
Update examples and installation instructions #224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…to Travis build. Carthage doesn't seem to really support local relative paths, so added a script to generate a cartfile with a full path to the git repo.
…ts to bin/. This means building projects the normal Carthage or CocoaPods way will work and will pull down the library from github. Cartfile.resolved and Podfile.lock have ben gitignored so that when a release is made a subsequent update to those files isn't required. The samples should always point to the latest version of the SDK in that branch as well. Further of note, the samples won't necessarily always build using the provided Cartfile or Podfile since they don't reference the branch version of the SDK. In other words, they'll only be expected to work for the latest release tag in master. Only the travis build scripts will work in a general sense for any branch and any changeset.
Manifests when running simulate_travis.sh or when building for tests in Xcode. https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html
…nd Cartfile are used for travis builds. This seems less likely to cause issue down the road when unexpected things happen after running simulate_travis.sh since changes to these files will be apparent in git.
….sh to work with different targets
1 similar comment
masojus
approved these changes
May 23, 2017
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. I'm glad we're verifying various methods of using the SDK now via CI. I didn't see anything that stood out as blocking. Thanks!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update installation instructions. A bridging header isn't necessary for Swift if linking against a Framework. Frameworks should also be linked as "Embedded Binaries."
Also remove ObjC and Swift examples from SDK workspace and create new projects/workspaces for each with versions of each using CocoaPods and Carthage. These are built as part of the Travis build to validate that the SDK will work with both types of projects and both languages.
I mostly left the existing examples intact, but removed some old non-ARC stuff from the ObjC example and changed the Swift example to link to KeenClient as a framework and do the proper imports instead of using a bridging header.