Daniel Duan's Articles About Carthage

Daniel Duan's Articles About Carthage https://duan.ca/tag/carthage/ Making An Open-Source Swift Project This video shows what it takes to open source a Swift project. Starting from some code in a playground, I created a framework that supports distribution via Swift Package Manager, CocoaPods, Xcode project and Carthage. The framework can be used across iOS, macOS, watchOS, tvOS and Linux. In addition, we also added SwiftLint to the project, added a Makefile, put everything on GitHub and set up continuous integration via Travis. README, COC, LICENSE and CHANGELOG are stubbed in as well. <div class="video-container"> <iframe src="https://www.youtube.com/embed/pA0T1CdqMt8" frameborder="0" gesture="media" allow="encrypted-media" allowfullscreen></iframe> </div> This is not at all a comprehensive list of things a good Open Source project should have. We are still missing the version tag, documentation generation, automatic Carthage binary generation, test coverage... Anyways, here's some stuff mentioned in the video: <ul> <li>Sample project from the video: <a href="https://github.com/dduan/BitArray">https://github.com/dduan/BitArray</a></li> <li>Video of me writing the code in this project: <a href="https://www.youtube.com/watch?v=-k_jrIoD56k">https://www.youtube.com/watch?v=-k_jrIoD56k</a></li> <li>Swift Package Manager: <a href="https://swift.org/package-manager/">https://swift.org/package-manager/</a></li> <li>CocoaPods: <a href="https://cocoapods.org">https://cocoapods.org</a></li> <li>Carthage: <a href="https://github.com/Carthage/Carthage">https://github.com/Carthage/Carthage</a></li> <li>Xcconfigs for universal framework: <a href="https://github.com/mrackwitz/xcconfigs">https://github.com/mrackwitz/xcconfigs</a></li> <li>SwiftLint: <a href="https://github.com/realm/SwiftLint">https://github.com/realm/SwiftLint</a></li> <li>Travis CI: <a href="https://travis-ci.org">https://travis-ci.org</a></li> </ul> Sun, 17 Dec 2017 21:24:43 -0800 https://duan.ca/2017/12/17/making-an-open-source-swift-project/ https://duan.ca/2017/12/17/making-an-open-source-swift-project/ Distribution Tests There are several ways to build dependencies for a Swift 3 project: Swift Package Manager, Cocoapods, Carthage, etc. Many have an opinion on which is the best choice for their projects. As a library author who want to help as many people as possible, however, they can't ignore any of them. I sometimes question the sanity of that conclusion: instead of becoming an export in each package manager, I find myself a novice of all. Did I break support for any of them with this project change? Is it still working on a particular platform, say, tvOS? Can I really know? The only way to really know is to verify yourself: both Cocoapods and Carthage support four platforms -- iOS, macOS, watchOS, tvOS; Swift Package Manager only works on Mac or Linux. So that's 2*4+1=9 targets. All these targets need is have the library in question fetched and imported. Every Swift library author should have such verification before publishing updates of their project. The steps to verify can be triggered with commands: fetch and build dependencies, build Xcode/Swift project. To automate the process, put these commands in a script or a Makefile. But wait, there's more! One shouldn't have to create these dummy projects every time they create a new library. If all these projects do is importing a library and attempt to build, they should work for any library. The config in <code>Package.swift</code>/<code>Cocoapods</code>/<code>Cartfile</code> and the <code>import</code> statements just needs some strings replaced: name of the next library, URL for its git repository, etc. And that's a scriptable process as well! To recap, one could, in theory, copy in some dummy projects, run a command to inject information about a new library, run another command to build all these project, verifying that support for those package managers remain functional. In reality, I have created <a href="https://github.com/dduan/DistributionTests">DistributionTests</a> and put it on <a href="https://github.com/dduan/DistributionTests">Github</a> 😉. The script <code>customize</code> requires 3 pieces of information of the library: its import name, its git repository URL and a major version number. The assumption here is the library generates uniformly named artifacts: the file name for <code>.framework</code> and the name users use to import it are the same. Testing distribution of a library is as simple as: <ol> <li>clone the project.</li> <li>customize the project with <code>customize</code>.</li> <li>run <code>make</code>.</li> </ol> If you do step 1 and 2, include the projects in library's repository, then only step 3 is necessary! This makes testing distribution methods trivial on a continuous integration server. Go forth and create fearlessly! Mon, 10 Oct 2016 10:34:49 -0700 https://duan.ca/2016/10/10/distribution-tests/ https://duan.ca/2016/10/10/distribution-tests/