Migrate objective c to swift11/21/2023 ![]() Next, let's move on to creating the PolygonKitObjC and PolygonKitSwift modules. Voila! Our very first C++ SPM module is now successfully compiled and ready to be imported into other modules. It's important to note the significance of the publicHeadersPath - it specifies the directory that contains the public interface with the functionality we need to make public.target( Additionally, we need to set the C++ HeaderSearchPath to the Polyutils directory, as this is required for the Polyutils repo to compile. Secondly, we must exclude a couple of unnecessary Java files from the Polyutils repo and set the publicHeadersPath to reference the "include" directory. We can then create its header and implementation files: PolyutilsKit.h and PolyutilsKit.m. However, there are a couple of things we can do to rectify this.įirstly, we need to create an "include" folder where we can add public headers that we want to expose to other modules. git mv modern-swiftui/PolygonKitStatic/Native\ submodule/polyutils Sources/PolyutilsPackageĪfter moving our submodule into place, it's apparent that our module is still not compiling. Let’s execute it for our project submodule. For the newer git version( > 1.8.5) there’s a git command ( git mv) that does everything for you, we just need to specify the old path and the new path. ![]() Let’s address the git submodule issue now as we need its files for our PolyutilsPackage module. Let's begin with the PolyutilsPackage module by adding its product, target to Package.swift and folder in the Sources directory. |- Sources |- Model … … … |- PolyutilsPackage … … … |- PolygonKitObjC … … … |- PolygonKitSwift … … … |- Tests Step 3: Implement SPM modules Here is our new structure of SPM modules and their targets: |- Packages |- README |- Package.swift ![]() We can then import it into our PolygonKit Obj-C target, which provides the interface for the PolygonKit Swift target. Given this context, it's clear that we'll need to define a separate module for the Polyutils repo, which contains only C++ codebase. However, for now, let's set this aside and address it later in the post. This means that we will need to move our submodule from the PolygonKitStatic path to the new SPM module path. You’ve probably noticed that our framework contains both Obj-C and C++ codebase, which means we need to restructure our PolygonKit module and separate it into at least two targets with their respective folders, as mixed languages cannot be contained in the same SPM target.Īdding to the complexity, the PolygonKitStatic framework directory also has a git submodule repo - Polyutils - which is written in C++ and imported into Obj-C interfaces, bridging its functionality to our PolygonPoint and Polygon Swift classes. PolygonKitStatic framework structureĪnd consider how we can restructure it to fit within our new SPM module(s). Adding PolygonPoint.swift file to SPM Model Package Step 2: Design mixed languages modulesīefore we proceed, let's analyze the contents of our PolygonKitStatic library represented in Figure 1. To resolve this, we'll need to migrate this framework to an SPM module and import it into our new SPM Model. However, the SPM won't compile just yet because we need the PolygonKitStatic library. Then, we'll add the first file to our new SPM Model module - PolygonPoint.swift - by copying the existing class from the old PolygonPoint in the new Model SPM module. To start, we'll create a new SPM Model package by adding a library product, and a target creating a new folder under the Sources directory named Model. ![]() Now, let's start with this example where you want to create your first Model module: Figure 2. PolygonKitStatic framework structure Step 1: Create the first Model SPM module Its structure is ilustrated in the following figure. To do this, you'll need to create individual targets for each programming language.Īs our example for today, we will use a static framework, namely the PolygonKitStatic module. While SPM modularization is generally straightforward, restructuring your module is necessary in the case of a mixed language codebase, such as Swift/Obj-C/C++. If you're working on a project that has been modularized the old way, you might be tasked with migrating previous static or target frameworks to Swift Package Manager (SPM). SPM's brilliance lies in its simple and transparent Package.swift file that configures all modules, making it easy for developers to understand and manage dependencies, whether at the module-specific or overall level. It could be done using the old way: adding new targets (modules) but that comes with a lot of project configuration which generally increases the project complexity. With SPM, you can create separate modules for different parts of your codebase and manage their dependencies in a clean and efficient way. Swift Package Manager(SPM) provides a powerful system of modularizing Swift projects.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |