![\"Linux\"](\"https:\/\/img.shields.io\/badge\/OS-Linux-blue.svg?style=flat\")
![\"Swift](\"https:\/\/img.shields.io\/badge\/Swift-2.2-orange.svg?style=flat\")
<\/p>\n <\/p>\n
Update:<\/b> If you don’t have Swift installed yet, head on over to our Ubuntu Packages<\/a> page and get the latest with In today’s world any serious programming language is going to come with a package manager<\/a>, an application designed to aid managing the distribution and installation of software “packages”. Ruby has a de jure<\/i> package management system with the rubygems<\/a> application, formally added to the language in Ruby 1.9. Python has various competing package management systems with pip, easy_install, and others. NodeJS applications and libraries are delivered via npm<\/a>.<\/p>\n As a part of the open source release of Swift, Apple has released a Swift Package Manager<\/a> designed for “managing distribution of source code, aimed at making it easy to share your code and reuse others\u2019 code.” This is a bit of understatement of what the Swift Package Manager can do in that its real power comes in managing the compilation and link steps of a Swift application.<\/p>\n In our previous tutorial<\/a> we explored how to build up a Swift application that relied on Glibc functions, linking against libcurl routines with a bridging header, and linking against a C function we compiled into an object file. You can see from the Makefile<\/a>, there are a lot of steps and commands involved!<\/p>\n In this post we’re going to replace all that with a succinct and clean Swift Package Manager Unlike There’s quite a bit of documentation available for the Swift Package Manager on Github, so I won’t rehash it here, but will rather dive right in to a working example of a Each Don’t let the “declarative” nature fool you, this is Swift code. The name attribute is self-explanatory, and The Swift Package Manager authors have devised an interesting mechanism by which to pull in package dependencies which relies on Git<\/a> and git tags. We’ll get to that in a moment.<\/p>\n The Swift Package Manager relies on the convention over configuration<\/i><\/a> paradigm for how to organize your Swift source files. By this we simply mean, if you follow the convention the package manager expects, then you have to do very little with your In short, the Swift Package Manager is happiest when you organize things like this:<\/p>\n In our Two new Now, here is where it gets really simple to build! Type That’s it! Our binary is placed in Running our application:<\/p>\n Let’s talk about the two dependencies listed in our and the The format of the All this file does is map a native C library and headers to a Swift module. In short, if you create a The authors of the Swift Package Manager, in the System Modules<\/i> documentation state:<\/p>\n \nThe convention we hope the community will adopt is to prefix such modules with C and to camelcase the modules as per Swift module name conventions. Then the community is free to name another module simply JPEG which contains more \u201cSwifty\u201d function wrappers around the raw C interface.\n<\/p><\/blockquote>\n Interpretation: if you’re providing a straight-up modulemap file and exposing C functions, name the module CPACKAGE. If at a later date you write a Swift API that uses CPACKAGE underneath, you can call that module PACKAGE. Thus when you see CJSONC and CcURL above you know that you’re dealing with direct C routines.<\/p>\n There are several examples of creating system modules in the documentation, but we’ll add one more. Creating a system module is broken down into 3 steps:<\/p>\n In this directory ( Package dependencies in Now, I’m not sure if git tags will be the only way to specify the version of your package; it does have the downside of tying one to using git for source control of your Swift code.<\/p>\n In our CDB directory.<\/p>\n And the crucial step:<\/p>\n Now we want to use our new module. In a separate directory named It’s important to note here your directory structure should look like this:<\/p>\n In What Now let’s say you made an error and needed to change up To use our new system module we write a quick Use It has been less than a week since Apple put Swift and the new package manager out on Github. It’s under heavy churn right now and will undoubtedly rapidly gain new features as time goes on, but it is a great start to being able to quickly build Swift applications on a Linux system!<\/p>\n You can get the new version of our translator application which uses the Swift Package Manager on Github.<\/p>\n Update: If you don’t have Swift installed yet, head on over to our Ubuntu Packages page and get the latest with apt-get install. In today’s world any serious programming language is going to come with a package manager, an application designed to aid managing the distribution and installation of software “packages”. Ruby has a de […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,19,5],"tags":[],"class_list":["post-2040","post","type-post","status-publish","format-standard","hentry","category-apple","category-linux","category-swift"],"_links":{"self":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/2040"}],"collection":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/comments?post=2040"}],"version-history":[{"count":32,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/2040\/revisions"}],"predecessor-version":[{"id":2812,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/2040\/revisions\/2812"}],"wp:attachment":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/media?parent=2040"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/categories?post=2040"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/tags?post=2040"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}apt-get install<\/code>.<\/p>\nPackage.swift<\/code> manifest and simplify our code while we’re at it.<\/p>\nPackage.swift<\/h2>\n
Package.swift<\/code> is the equivalent of npm<\/b>s package.json<\/code>. It is the blueprint and set of instructions from which the Swift Package Manager will build your application. As of this writing (December 8, 2015), Package.swift<\/code> contains information such as:<\/p>\n\n
package.json<\/code> however, Package.swift<\/code> is<\/i> Swift code, in the same way an SConstruct<\/code><\/a> file is Python. As the Swift Package Manager evolves to meet the complex use cases of building large software packages it will undoubtedly grow to contain additional metadata and instructions on how to build your package (for example, package.json<\/code> for NodeJS contains instructions on how to execute your unit tests).<\/p>\nPackage.swift<\/code> for our translator application.<\/p>\n\nimport PackageDescription\n\nlet package = Package(\n name: \"translator\",\n dependencies: [\n .Package(url: \"https:\/\/github.com\/iachievedit\/CJSONC\", majorVersion: 1),\n .Package(url: \"https:\/\/github.com\/PureSwift\/CcURL\", majorVersion: 1)\n ]\n)\n<\/pre>\n
Package.swift<\/code> file starts off with import PackageDescription<\/code>. PackageDescription<\/code> is a new Swift module that comes with the binary distribution of Swift for the Ubuntu system. The class Package<\/code> is provided, which we utilize on the next line.<\/p>\npackage<\/code> gets assigned a new Package<\/code> object which we’ve created with the init(name: String? = nil, targets: [Target] = [], dependencies: [Dependency] = [])<\/code> initializer.<\/p>\ndependencies<\/code> is an array of package dependencies. Our application will rely on two packages, CJSONC (which is a wrapper around libjson-c), and CcURL (a wrapper around, you guessed it, libcurl).<\/p>\nDirectory Structure<\/h2>\n
Package.swift<\/code>. Notice that we didn’t specify the name of our source files in it. We don’t have to because the package manager will figure it out by looking in expected locations.<\/p>\n\nproject\/Package.swift\n \/Sources\/sourceFile.swift\n \/Sources\/...\n \/Sources\/main.swift\n<\/pre>\n
Sources<\/code> directory we will place two files: Translator.swift<\/code> and main.swift<\/code>. Note:<\/b> Our previous tutorial used lowercase filenames, such as translator.swift<\/code>. This convention is used by NodeJS developers. It appears that the Swift community is going with capitalized filenames.<\/p>\nTranslator.swift<\/code> has changed a bit from our previous version. Here is the new version which leverages system modules rather than trying to link against C object files we created by hand.<\/p>\n\nimport Glibc\nimport Foundation\nimport CcURL\nimport CJSONC\n\npublic class Translator {\n\n let BUFSIZE = 1024\n\n public init() {\n }\n\n public func translate(text:String, from:String, to:String,\n completion:(translation:String?, error:NSError?) -> Void) {\n\n let curl = curl_easy_init()\n\n guard curl != nil else {\n completion(translation:nil,\n error:NSError(domain:\"translator\", code:1, userInfo:nil))\n return\n }\n\n let escapedText = curl_easy_escape(curl, text, Int32(strlen(text)))\n\n guard escapedText != nil else {\n completion(translation:nil,\n error:NSError(domain:\"translator\", code:2, userInfo:nil))\n return\n }\n \n let langPair = from + \"%7c\" + to\n let wgetCommand = \"wget -qO- http:\/\/api.mymemory.translated.net\/get\\\\?q\\\\=\" + String.fromCString(escapedText)! + \"\\\\&langpair\\\\=\" + langPair\n \n let pp = popen(wgetCommand, \"r\")\n var buf = [CChar](count:BUFSIZE, repeatedValue:CChar(0))\n \n var response:String = \"\"\n while fgets(&buf, Int32(BUFSIZE), pp) != nil {\n response = response + String.fromCString(buf)!\n }\n \n let translation = getTranslatedText(response)\n\n guard translation.error == nil else {\n completion(translation:nil, error:translation.error)\n return\n }\n\n completion(translation:translation.translation, error:nil)\n }\n\n private func getTranslatedText(jsonString:String) -> (error:NSError?, translation:String?) {\n\n let obj = json_tokener_parse(jsonString)\n\n guard obj != nil else {\n return (NSError(domain:\"translator\", code:3, userInfo:nil),\n nil)\n }\n\n let responseData = json_object_object_get(obj, \"responseData\")\n\n guard responseData != nil else {\n return (NSError(domain:\"translator\", code:3, userInfo:nil),\n nil)\n }\n\n let translatedTextObj = json_object_object_get(responseData,\n \"translatedText\")\n\n guard translatedTextObj != nil else {\n return (NSError(domain:\"translator\", code:3, userInfo:nil),\n nil)\n }\n\n let translatedTextStr = json_object_get_string(translatedTextObj)\n\n return (nil, String.fromCString(translatedTextStr)!)\n \n }\n\n}\n<\/pre>\nimport<\/code> statements have been added for CJSONC<\/code> and CcURL<\/code>, and a routine we did<\/i> have in C is now in pure Swift. To be sure under the hood the compile and link system is relying on libraries that were compiled from C source code, but at the binary level, its all the same.<\/p>\nswift build<\/code> and watch magic happen:<\/p>\n\n# swift build\nCloning Packages\/CJSONC\nCloning Packages\/CcURL\nCompiling Swift Module 'translator' (2 sources)\nLinking Executable: .build\/debug\/translator\n<\/pre>\n
.build\/debug<\/code> and takes its name from our Package.swift<\/code> file. By default a debug build is created; if we want a release build, just add -c release<\/code> to the command:<\/p>\n\n# swift build -c release\nCompiling Swift Module 'translator' (2 sources)\nLinking Executable: .build\/release\/translator\n<\/pre>\n
\n# .build\/debug\/translator \"Hello world\\!\" from en to es\nTranslation: \u00a1Hola, mundo!\n<\/pre>\n
System Modules<\/h2>\n
Package.swift<\/code> manifest. If you go to the Github repository of either “packages” you will find very little. Two files, in fact:<\/p>\n\n
module.modulemap<\/code>\nPackage.swift<\/code>\n<\/ul>\nPackage.swift<\/code> file is actually empty!<\/p>\nmodule.modulemap<\/code> file and its purpose is described in the System Modules<\/a> section of the Swift Package Manager documentation. Let’s take a look at the CJSON one:<\/p>\n\nmodule CJSONC [system] {\n header \"\/usr\/include\/json-c\/json.h\"\n link \"json-c\"\n export *\n}\n<\/pre>\nmodulemap<\/code> file you can begin importing functions from all manner of libraries on your Linux system. We’ve created a modulemap for json-c<\/a> which is installed via apt-get<\/code> on an Ubuntu system.<\/p>\nCreating a System Module<\/h3>\n
\n
\nsudo apt-get install -y libdb5.3-dev # Since we're going to be using BerkeleyDB\nmkdir CDB\ncd CDB \ntouch Package.swift\n<\/pre>\n
CDB<\/code>) add module.modulemap<\/code> with the following contents:<\/p>\n\nmodule CDB [system] {\n header \"\/usr\/include\/db.h\"\n link \"db\"\n export *\n}\n<\/pre>\nPackage.swift<\/code> are specified with URLs and version numbers. Version.swift<\/code><\/a> lays out the current versioning scheme of major.minor.patch<\/code>. We need a mechanism by which to version our system module, and the Swift Package Managers have developed a scheme by which you can use git tags<\/a>.<\/p>\n\ngit init # Initialize a git repository\ngit add . # Add all of the files in our directory\ngit commit -m\"Initial Version\" # Commit\n[master (root-commit) d756512] Initial Version\n 2 files changed, 5 insertions(+)\n create mode 100644 Package.swift\n create mode 100644 module.modulemap\n<\/pre>\n
\ngit tag 1.0.0 # Tag our first version\n<\/pre>\n
use-CDB<\/code>, adjacent to our CDB<\/code> directory<\/code>, create a Package.swift<\/code> file:<\/p>\n\nimport PackageDescription\n\nlet package = Package(\n name:\"use-CDB\",\n dependencies:[\n .Package(url:\"..\/CDB\", majorVersion:1)\n ]\n)\n<\/pre>\n
\n CDB\/module.modulemap\n \/Package.swift\nuse-CDB\/Package.swift\n<\/pre>\n
use-CDB<\/code> run swift build<\/code>:<\/p>\n\n# swift build\nCloning Packages\/CDB\n<\/pre>\n
swift build<\/code> has done here is read the package descriptor and “pulled in” the dependency on the CDB<\/code> package. It so happens that this package is in your local filesystem vs. on a hosted Git repository like Github or BitBucket. The majorVersion<\/code> is the first tuple of your git tag.<\/p>\nmodule.modulemap<\/code>. You edit the file, commit it, and then run swift build<\/code> again. Unless<\/i> you retag you will not pick up these changes! Versioning in action. Either retag 1.0.0 with git tag -f 1.0.0<\/code> (-f<\/code> is for force), or bump your version number with a patch level, like git tag 1.0.1<\/code>.<\/p>\nmain.swift<\/code> in use-CDB<\/code>:<\/p>\n\nimport CDB\nimport Glibc\n\nvar myDatabase:UnsafeMutablePointer
swift build<\/code> and it will pull in our CDB<\/code> module for us to use. The next step is to figure out how to use the myDatabase<\/code> pointer to open the database!<\/p>\nClosing Remarks<\/h2>\n
Getting the Code<\/h3>\n
\n# git clone https:\/\/github.com\/iachievedit\/moreswift\n# cd translator_swiftpm\n# swift build\nCloning Packages\/CJSONC\nCloning Packages\/CcURL\nCompiling Swift Module 'translator' (2 sources)\nLinking Executable: .build\/debug\/translator\n<\/pre>\n","protected":false},"excerpt":{"rendered":"