All in regards to the Swift Bundle Supervisor and the Swift toolchain

0/5 No votes

Report this app

Description

[ad_1]

Be taught every part in regards to the SPM structure. I am going to additionally train you how one can combine your binary executable into the Swift toolchain.

Swift

If you do not know an excessive amount of in regards to the Swift Bundle Supervisor, however you might be searching for the fundamentals please learn my tutorial about SPM that explains just about every part. The intention of this text is to go deep into the SPM structure, additionally earlier than you begin studying this I might suggest to additionally learn my article about frameworks and instruments. 📖

Prepared? Go! I imply Swift! 😂


Swift Bundle Supervisor

Have you ever ever questioned about how does SPM parse it is manifest file with a view to set up your packages? Nicely, the Bundle.swift manifest is an odd beast. Let me present you an fast instance of a daily bundle description file:


import PackageDescription

let bundle = Bundle(
    title: "HelloSwift",
    dependencies: [
        
    ],
    targets: [
        .target(
            name: "HelloSwift",
            dependencies: []),
        .testTarget(
            title: "HelloSwiftTests",
            dependencies: ["HelloSwift"]),
    ]
)

The primary line comprises the model data, subsequent we’ve got to import the PackageDescription module which comprises all of the required parts to correctly describe a Swift bundle. If you happen to run for instance swift bundle replace all of your dependencies on this manifest file will likely be resolved & you should use them inside your individual code information. ✅

However how on earth are they doing this magic? 💫

That query was bugging me for some time, so I did a little analysis. First I used to be attempting to duplicate this behaviour with out wanting on the authentic implementation of the Swift Bundle Supervisor at github. I knew I shoudn’t parse the Swift file, as a result of that’d be a horrible factor to do – Swift information are messy – so let’s attempt to import it in some way… 🙃

Dynamic library loading strategy

I looked for the “dynamic swift library” key phrases and located an fascinating discussion board subject on swift.org. Yeah, I am making some progress I assumed. WRONG! I used to be manner farther from the precise answer than I although, but it surely was enjoyable, so I used to be wanting into the implementation particulars of how one can open a compiled .dylib file utilizing dlopen & dlsym from Swift. How does one create a .dylib file? Ah, I already know this! 👍

I all the time needed to grasp this subject higher, so I began to learn an increasing number of each about static and dynamic libraries. Lengthy story quick, you may create a dynamic (or static) library with the next product definition:


import PackageDescription

let bundle = Bundle(
    title: "instance",
    merchandise: [
        .library(name: "myStaticLib", type: .static, targets: ["myStaticLib"]),
        .library(title: "myDynamicLib", kind: .dynamic, targets: ["myDynamicLib"]),
    ],
    targets: [
        .target(
            name: "myStaticLib",
            dependencies: []),
        .goal(
            title: "myDynamicLib",
            dependencies: []),
    ]
)

The vital information are going to be situated contained in the .construct/debug folder. The .swiftmodule is principally the general public header file, this comprises all of the out there API on your library. The .swiftdoc file comprises the documentation for the compiled module, and relying on the kind you will additionally get a .dylib or a .a file. Guess which one is which.

So I might load the .dylib file through the use of dlopen & dlsym (some @_cdecl magic concerned to get fixed names as an alternative of the “fuzzy” ones), however I used to be consistently receiving the identical warning again and again. The dynamic loading labored nicely, however I needed to do away with the warning, so I attempted to take away the embedded the lib dependency from my executable goal. (Trace: probably not doable… afaik. anybody? 🙄)

I used to be messing round with rpaths & the install_name_tool for like hours, however even after I succesfully eliminated my library from the executable, “libSwift*issues” have been nonetheless embedded into it. So that is the unhappy state of an unstable ABI, I assumed… anyway not less than I’ve realized one thing essential throughout the way in which right here:

Importing Swift code into Swift!

Sure, you heard that. It is doable to import compiled Swift libraries into Swift, however not lots of people heard about this (I assume). It is not a well-liked subject amongs iOS / UIKit builders, however SPM does this on a regular basis behind the scenes. 😅

How on earth can we import the pre-built libraries? Nicely, it is fairly easy.



swiftc dynamic_main.swift -I ./.construct/debug -lmyDynamicLib -L ./.construct/debug
swiftc static_main.swift -I ./.construct/debug -lmyStaticLib -L ./.construct/debug



swift construct -Xswiftc -I -Xswiftc ./.construct/debug -Xswiftc -L -Xswiftc ./.construct/debug -Xswiftc -lmyStaticLib
swift construct -Xswiftc -I -Xswiftc ./.construct/debug -Xswiftc -L -Xswiftc ./.construct/debug -Xswiftc -lmyDynamicLib

You simply should append just a few compiler flags. The -I stands for the import search path, -L is the library search path, -l hyperlinks the given library. Examine swiftc -h for extra particulars and flags you will not remorse it! Voilá now you may distribute closed supply Swift packages. Not less than it was good to understand how SPM does the “trick”. 🤓

Please notice that till Swift 5 & ABI stability arrives you should use the precompiled libraries with the identical Swift model solely! So in the event you compile a lib with Swift 4.2, your executable additionally must be compiled with 4.2., however this can change fairly quickly. 👏

The Swift Bundle Supervisor technique

After 2 days of analysis & studying I actually needed to unravel this, so I’ve began to examine the supply code of SPM. The very first thing I’ve tried was including the --verbose flag after the swift construct command. Right here is the vital factor:

/Purposes/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc 
--driver-mode=swift 
-L /Purposes/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/pm/4_2 
-lPackageDescription 
-suppress-warnings 
-swift-version 4.2 
-I /Purposes/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/pm/4_2 
-target x86_64-apple-macosx10.10 
-sdk /Purposes/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk 
/Customers/tib/instance/Bundle.swift 
-fileno 5

Whoa, this spits out a JSON primarily based on my Bundle.swift file!!! 🎉

How the hell are they doing this?

It seems, in the event you change the -fileno parameter worth to 1 (that is the usual output) you may see the outcomes of this command on the console. Now the trick right here is that SPM merely compiles the Bundle.swift and if there’s a -fileno flag current within the command line arguments, nicely it prints out the encoded JSON illustration of the Bundle object after the method exits. That is it, fuckn’ simple, but it surely took 1 extra day for me to determine this out… parenting 2 children & coding is a tough mixture. 🤷‍♂️

If you happen to open the /Purposes/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/pm/4_2 folder you will see 3 acquainted information there. Precisely. I additionally regarded on the supply of the Bundle.swift file from the SPM repository, and adopted the registerExitHandler technique. After a profitable Bundle initialization it merely registers an exit handler if a -fileno argument is current encodes itself & dumps the outcome through the use of the file handler quantity. Candy! 😎

Since I used to be just about within the end lap, I needed to determine yet one more factor: how did they handle to place the swift bundle command beneath the swift command?


Swift toolchain

I simply entered swift lol into my terminal. That is what occurred:

[email protected]~: swift lol
error: unable to invoke subcommand:
/Purposes/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-lol
(No such file or listing)

Acquired ya! The toolchain is the important thing to every part:

  1. Apple is compiling the PackageDescription library from the Swift Bundle Supervisor and places the .swiftmodule, .swiftdoc, .dylib information into the correct locations beneath Xcode’s default toolchain library path.
  2. The swift construct, run, check subcommands are simply one other Swift binary executables positioned contained in the toolchain’s binary path. (Named like: swift-package, swift-build, swift-run, swift-test)
  3. The swift command tries to invoke the correct subcommand if there’s any and it is a legitimate (Swift) binary. (Tried with a shell script, it failed miserably…)
  4. SPM makes use of the PackageDescription library from the toolchain with a view to compile & flip the manifest file into JSON output.
  5. The remainder is historical past. 🤐

Swift can resolve subcommands from anyplace “inside” the PATH variable. You simply should prefix your Swift script with swift- and also you’re good to go.


SwiftCI – a job runner for Swift

I had this concept that it might be good to have a grunt / gulp like job runner additionally a steady integration sercie on a long run through the use of this method I defined above. So I’ve made the same extension wired into the guts of the Swift toolchain: SwiftCI. ❤️

You may seize the proof-of-concept implementation of SwiftCI from github. After putting in it you may create your individual CI.swift information and run your workflows.

import CI

let buildWorkflow = Workflow(
    title: "default",
    duties: [
        Task(name: "HelloWorld",
             url: "[email protected]:BinaryBirds/HelloWorld.git",
             model: "1.0.0",
             inputs: [:]),

        Job(title: "OutputGenerator",
             url: "~/ci/Duties/OutputGenerator",
             model: "1.0.0",
             inputs: [:]),

        Job(title: "SampleTask",
             url: "[email protected]:BinaryBirds/SampleTask.git",
             model: "1.0.1",
             inputs: ["task-input-parameter": "Hello SampleTask!"]),
    ])

let testWorkflow = Workflow(
    title: "linux",
    duties: [
        Task(name: "SampleTask",
             url: "https://github.com/BinaryBirds/SampleTask.git",
             version: "1.0.0",
             inputs: ["task-input-parameter": "Hello SampleTask!"]),
        ])

let undertaking = Mission(title: "Instance",
                      url: "[email protected]:BinaryBirds/Instance.git",
                      workflows: [buildWorkflow, testWorkflow])

The code above is a pattern from a CI.swift file, you may merely run any workflow with the swift ci run workflow-name command. The whole lot is 100% written in Swift, even the CI workflow descriptor file. I am planning to increase my ci namespace with some useful subcommands afterward. PR’s are greater than welcomed!

I am very proud of the outcome, not simply due to the closing product (that is solely a proof of idea implementation), however principally due to the issues I’ve realized throughout the creation course of. If you wish to get extra ideas and matters like this you must comply with me on Twitter and subscribe to my month-to-month e-newsletter.



[ad_2]

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.