Daniel Duan's Articles About SwiftPM

Daniel Duan's Articles About SwiftPM https://duan.ca/tag/swiftpm/ Using Instruments on Non-macOS, Non-iOS Executables How do you use use Instruments, the instrumentation tool distributed alongside Xcode? It's easy if you are profiling a macOS or iOS app. No so with a regular old command-line tool built, say, with SwiftPM. To do so, you'll need to codesign the target binary. Otherwise Instruments will give you a <code>"Failed to gain authorization"</code> error message. Here's the steps: <ol> <li>Create a entitlement file with <code>com.apple.security.get-task-allow</code> set to true:</li> </ol> <pre><code class="language-xml"><?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.get-task-allow</key> <true/> </dict> </plist> </code></pre> Let's call it <code>Entitlements.plist</code> <ol start="2"> <li> Build the executable. </li> <li> Codesign your executable with the entitlement file </li> </ol> <pre><code>codesign -s - -f --entitlements path/to/Entitlements.plist path/to/executable </code></pre> Now proceed with your profiling in Instruments. Not sure where this is officially documented. So I'm officially documenting it here. Thu, 31 Mar 2022 20:39:05 -0700 https://duan.ca/2022/03/31/instrumenting-commandline-executables/ https://duan.ca/2022/03/31/instrumenting-commandline-executables/ Building IndexStoreDB on Linux: The Portable Technique <h2>The problem</h2> As of writing of this article, when you attempt to use Apple's Swift library <a href="https://github.com/apple/indexstore-db">IndexStoreDB</a> on Linux as a normal SwiftPM dependency, it won't build successfully: <pre><code class="language-fish">❯ cat Package.resolved { "object": { "pins": [ { "package": "IndexStoreDB", "repositoryURL": "https://github.com/apple/indexstore-db", "state": { "branch": "swift-5.5.2-RELEASE", "revision": "e771994778265c2efe8d33a7ca30adf5f3d2065a", "version": null } } ] }, "version": 1 } ❯ swift build > /dev/null ❯ echo $status 1 </code></pre> The issue is documented in the build instruction for Linux: <blockquote> The C++ code in the index requires <code>libdispatch</code>, but unlike Swift code, it cannot find it automatically on Linux. You can work around this by adding a search path manually. </blockquote> <pre><code>$ swift build -Xcxx -I<path_to_swift_toolchain>/usr/lib/swift -Xcxx -I<path_to_swift_toolchain>/usr/lib/swift/Block </code></pre> Okay, so, how would my package build in Linux environments where the Swift toolchain's setup is unknown? How do we avoid building with one toolchain while mixing in <code>libdispatch</code> from another toolchain somewhere? Here's what I did for my command-line tool <a href="https://github.com/dduan/Clue">Clue</a>. <h2>The solution</h2> The essence of the problem is about the installation location of the Swift toolchain. Our solution makes the following assumptions: <ol> <li>A Swift toolchain is installed on the file system on Linux (duh!).</li> <li>The toolchain is at least similar to the one distributed on Swift.org. So <code>libdispatch</code> is distributed alongside the other binaries, in a stable relative directory.</li> </ol> Having the <code>swift</code> command available (assumption #1), we can just let it tell us about itself with the <code>-print-target-info</code> flag: <pre><code class="language-fish">❯ swift -print-target-info { "compilerVersion": "Swift version 5.5.2 (swift-5.5.2-RELEASE)", "target": { "triple": "x86_64-unknown-linux-gnu", "unversionedTriple": "x86_64-unknown-linux-gnu", "moduleTriple": "x86_64-unknown-linux-gnu", "compatibilityLibraries": [ ], "librariesRequireRPath": false }, "paths": { "runtimeLibraryPaths": [ "/home/dan/.swiftenv/versions/5.5.2/usr/lib/swift/linux" ], "runtimeLibraryImportPaths": [ "/home/dan/.swiftenv/versions/5.5.2/usr/lib/swift/linux", "/home/dan/.swiftenv/versions/5.5.2/usr/lib/swift/linux/x86_64" ], "runtimeResourcePath": "/home/dan/.swiftenv/versions/5.5.2/usr/lib/swift" } } </code></pre> Great! We see where the runtime is installed. Now we can invoke assumption #2, that <code>libdispatch</code> is at a relative location to the rest of the runtime. In the output from above, the value for <code>runtimeResourcePath</code> happens to be the parent directory for <code>libdispatch</code>'s headers. The <code><path_to_swift_toolchain></code> value in <a href="https://github.com/apple/indexstore-db">IndexStoreDB</a>'s official instruction in this particular setup would be <code>/home/dan/.swiftenv/versions/5.5.2</code>. So the following command would have worked: <pre><code>swift build -Xcxx -I/home/dan/.swiftenv/versions/5.5.2/usr/lib/swift -Xcxx -I/home/dan/.swiftenv/versions/5.5.2/usr/lib/swift/Block </code></pre> All we need to do is parse this information at build time, and it should work on every Linux setup! Choose whatever parsing method you like. Here's (more or less) the <code>Makefile</code> for <a href="https://github.com/dduan/Clue">Clue</a>: <pre><code class="language-make">SHELL = /bin/bash ifeq ($(shell uname),Darwin) EXTRA_SWIFT_FLAGS = "--disable-sandbox" else SWIFT_TOOLCHAIN = "$(shell swift -print-target-info | grep runtimeResourcePath | cut -f 2 -d ':' | cut -f 2 -d '"')" EXTRA_SWIFT_FLAGS = -Xcxx -I${SWIFT_TOOLCHAIN} -Xcxx -I${SWIFT_TOOLCHAIN}/Block endif define build @swift build --configuration $(1) -Xswiftc -warnings-as-errors ${EXTRA_SWIFT_FLAGS} endef .PHONY: build build: $(call build,release) .PHONY: test test: @swift test ${EXTRA_SWIFT_FLAGS} .PHONY: debug debug: $(call build,debug) </code></pre> <ol> <li><code>make build</code> / <code>make test</code> / <code>make debug</code> all work as expected, building IndexStoreDB successfully.</li> <li>As-is, this snippet is project-agnostic. So you can throw it in your SwiftPM project and it should "just work".</li> </ol> Alright! Wed, 09 Feb 2022 15:58:41 -0800 https://duan.ca/2022/02/09/building-indexstoredb-on-linux/ https://duan.ca/2022/02/09/building-indexstoredb-on-linux/