Daniel Duan's Articles About Make

Daniel Duan's Articles About Make https://duan.ca/tag/make/ 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/ Deploy Jekyll Site To Github With Make At risks of being too meta, I want to talk about how this post is going to go from my computer to a repository on Github on both the <code>master</code> and <code>gh-pages</code> branch. The former contains the file I'm typing, and the latter an updated HTML site generated by Jekyll. Here's how: I type <code>make deploy</code> once I commit this file in my local repository. I spent a day to set up a Jekyll site. The last part involves deploying it to Github, my preferred way to host a static site. There are a lot of posts and scripts on how to achieve it. And Github seems to have an "afficial" support for Jekyll site that disables plugin scripts (understandably so). But having worked with git and make for all these years made me immune to all the fanciness the Internet tries to sell. Here's my script for deploying a Jekyll project to Github pages: <pre><code>DEPLOY_PATH=/tmp/jekyll_deploy build: jekyll build deploy: git checkout -f gh-pages git clean -d -x -f git pull git checkout master jekyll build rm -rf ${DEPLOY_PATH} mkdir ${DEPLOY_PATH} cp -R .git ${DEPLOY_PATH} cd ${DEPLOY_PATH}; git checkout gh-pages; git clean -d -x -f cp -R _site/* ${DEPLOY_PATH} cd ${DEPLOY_PATH}; git add .; git commit -m "`curl whatthecommit.com/index.txt`" cd ${DEPLOY_PATH}; git push -f origin gh-pages </code></pre> Drop it into root of your Jekyll project, commit all changes (including the <code>Makefile</code>). And type <code>make deploy</code>. BOOM, done. There are a couple of assumptions: <ul> <li>You build the site in the <code>_site</code> folder</li> <li>You store Jekyll source on <code>master</code> and have the <code>gh-pages</code> branch up.</li> <li>You can build the site by running <code>jekyll build</code>.</li> <li>You don't care about commit message on the deploy branch.</li> </ul> I like it better than other methods because it does not require installing additional software/scripts and there's no restriction on plugins. Sun, 15 May 2016 01:00:00 -0700 https://duan.ca/2016/05/15/deploy-jekyll-to-github/ https://duan.ca/2016/05/15/deploy-jekyll-to-github/ NeoVim, Swift and Make When it comes to Swift source code editing, nothing beats Xcode 6.3! That includes Xcode 6.2, which drove me to good'O Vim for a while. Except it's not the old Vim, I'm trying out <a href="http://neovim.org">NeoVim</a>. The most noticable difference in NeoVim compared to Vim is its recent addition of a built-in terminal. With the help of syntax highlighting and a Makefile, working with Swift this way turns out to be a fine alternative. (As a side benefit, I'm forced to use only local-context autocompletion. Now I can actually spell out full UIKit APIs 😉.) Here's a gif: <img src="/assets/2015/04/demo.gif" alt="Make Swift NeoVim Demo" /> Some details are easy to miss. I pressed <code>,m</code>, <code>,</code> being my binding for <code><leader></code>. A terminal session launched with the <code>make</code> command running. When that's done, I could press any key and the terminal pane was dismissed. Since <code>test</code> is the default target in my <code>Makefile</code>, the test suit for my Swift codes actually ran. Here's how the shortcut is set in <code>.nvimrc</code>: <pre><code>if has('nvim') nnoremap <leader>m :rightbelow vertical split <bar> :term make<cr> endif </code></pre> The makefile is pretty straightforword if you've worked with <code>xcodebuild</code>. <pre><code>test : @xcodebuild test -project ProjectName.xcodeproj -scheme SchemeName -destination 'platform=iOS Simulator,name=iPhone 6' | xcpretty clean : @xcodebuild clean </code></pre> <a href="https://github.com/supermarin/xcpretty">xcpretty</a> is a nifty script that makes <code>xcodebuild</code>s output much more readable. Happy vimming, Swifties :) Wed, 22 Apr 2015 11:46:17 -0700 https://duan.ca/2015/04/22/neovim-swift-and-make/ https://duan.ca/2015/04/22/neovim-swift-and-make/