Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18
  1. #11
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    101
    Thanks for your information. We will surely take a second look at supporting SPM.

    And sorry for the late answer, unfortunately your post was flagged for moderation (probably due to links) and it went under our radars.

  2. #12
    Member
    Join Date
    Oct 2019
    Location
    Berlin
    Posts
    9
    Hello again Gianluca (and Boris),

    Sorry to revive this old post. After some research and with the release of Swift 5.3, I believe I found a way to deliver Lighstreamer binaries through SPM that doesn't require code changes, just a Xcode rebuild.

    Let me summarize the current state of things:
    1. Lightstreamer transpiles Java to ObjC and delivers four dynamic libraries in the shape of .framework files (for macOS, iOS, tvOS, and watchOS).
    2. End-clients wanting to use Lightstreamer functionality just needs to embed/link the selected Lighstreamer framework file in their Xcode project.
    3. More often than not, the Lighstreamer dynamic framework is just one low-level component within a major library. A good example is IG (company where Boris works). IG uses Lightstreamer as their "real-time" messaging system, but they offer much more functionality.
    4. Swift programmers wanting to use IG services, need to know all dependencies and their requirements, manually download them, embed/link the dependency frameworks, and set correctly all the build settings (they need to be careful since there are different dynamic libraries per target platform: macOS x86-64, macOS arm64, iOS arm64, iOS x86 simulator, tvOS arm64, tvOS simulator, etc.).

    The goal is to make life as simple as possible for the end user. Ideally, a user specify a SPM url in his/her project, and all the required dependencies (for the right platforms) are downloaded and compiled.

    SPM and Swift 5.3 enable this through the new .binaryTarget. It is now possible to specify binary dependencies, by providing a URL and a checksum. The only caveat is that the binary dependency must be exposed as a .xcframework. A xcframework is just a standard bundle of compiled binaries. It is actually possible to create a single xcframework from all the already released Lighstreamer dynamic libraries, by using the following terminal command:

    xcodebuild -create-xcframework \
    -framework Lightstreamer_iOS_Client.framework \
    -framework Lightstreamer_macOS_Client.framework \
    -framework Lightstreamer_tvOS_Client.framework \
    -output Lightstreamer.xcframework


    Sadly,this command fails because the iOS and tvOS frameworks currently bundle both their arm64 code and the x86 simulator code. xcframework enforces that each framework must only target a single architecture. Therefore, for this command to work there must be a framework for each architecture: iOS arm64, iOS simulator, tvOS arm64, tvOS simulator, etc.

    So Gianluca, I would kindly ask you to do one of the following things:
    - Provide a framework per platform architecture (do not bundle simulator and real device code), or
    - Provide a xcframework zip file.

    This would enable the delivery of Swift Packages, ease the use of the Lighstreamer framework, and reduce the amount of compilation/linking errors. Personally, I need a xcframework for Lightstreamer Allegro Presto Vivace 6.1.0 2017/01/23 (unified API 2.1.2), since this is what IG support. Is it possible to receive such xcframework zip file?

  3. #13
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    101
    Hello,

    thank you for your valuable insights into the problem. I will surely take a look and let you know.

  4. #14
    Member
    Join Date
    Oct 2019
    Location
    Berlin
    Posts
    9
    Great. Looking forward your analysis/response. In the meantime, you can find a project currently delivering Lighstreamer binaries through SPM here. That project delivers a library (which can statically or dynamically linked) and a packaged Lighstreamer.xcframework.

    Regards,

  5. #15
    Creating an XCFramework for the Lightstreamer iOS Client

    1. Create a work directory structure:
    work/
    os/
    sim/

    mkdir -p work/os work/sim

    2. Change directory into work.
    cd work

    3. Download the Lightstreamer iOS Client.
    curl -O https://www.lightstreamer.com/repo/c...ient-4.2.1.zip

    4. Unzip ls-ios-client-4.2.1.zip
    unzip ls-ios-client-4.2.1.zip

    5. Copy the Lightstreamer_iOS_Client.framework directory into os/ and sim/
    cp -r Lightstreamer_iOS_Client.framework os
    cp -r Lightstreamer_iOS_Client.framework sim

    6. Change directory into os/Lightstreamer_iOS_Client.framework
    cd os/Lightstreamer_iOS_Client.framework

    7. List all of the architectures included in the Lightstreamer_iOS_Client file.
    lipo -info Lightstreamer_iOS_Client

    8. Remove all architectures from the Lightstreamer_iOS_Client file, except arm64
    lipo -remove i386 Lightstreamer_iOS_Client -output Lightstreamer_iOS_Client
    lipo -remove x86_64 Lightstreamer_iOS_Client -output Lightstreamer_iOS_Client
    lipo -remove armv7 Lightstreamer_iOS_Client -output Lightstreamer_iOS_Client

    9. Change directory into sim/Lightstreamer_iOS_Client.framework
    cd ../../sim/Lightstreamer_iOS_Client.framework

    10. List all of the architectures included in the Lightstreamer_iOS_Client file.
    lipo -info Lightstreamer_iOS_Client

    11. Remove all architectures from the Lightstreamer_iOS_Client file, except x86_64
    lipo -remove i386 Lightstreamer_iOS_Client -output Lightstreamer_iOS_Client
    lipo -remove armv7 Lightstreamer_iOS_Client -output Lightstreamer_iOS_Client
    lipo -remove arm64 Lightstreamer_iOS_Client -output Lightstreamer_iOS_Client

    12. Change directory into work
    cd ../../

    13. Create the XCFramework.
    xcodebuild -create-xcframework -framework os/Lightstreamer_iOS_Client.framework -framework sim/Lightstreamer_iOS_Client.framework -output Lightstreamer_iOS_Client.xcframework



    Creating a Swift Package for Lightstreamer_iOS_Client.xcframework

    1. Create a directory in which to make the package.
    mkdir Lightstreamer_iOS_Client

    2. Change into the package directory.
    cd Lightstreamer_iOS_Client

    3. Initialize the package.
    swift package init --type library

    4. Remove unneeded files.
    rm -rf Sources Tests

    5. Copy the Lightstreamer_iOS_Client.xcframework directory to the package directory.
    cp -r ../path/to/Lightstreamer_iOS_Client.xcframework .

    6. Modify the Package.swift file to add the xcframework.
    // swift-tools-version:5.3
    // The swift-tools-version declares the minimum version of Swift required to build this package.

    import PackageDescription

    let package = Package(
    name: "Lightstreamer_iOS_Client",
    products: [
    .library(name: "Lightstreamer_iOS_Client", targets: ["Lightstreamer_iOS_Client"])
    ],
    dependencies: [],
    targets: [
    .binaryTarget(name: "Lightstreamer_iOS_Client", path: "Lightstreamer_iOS_Client.xcframework")
    ]
    )

    At this stage, the package is ready to be hosted in git.

  6. #16
    Member
    Join Date
    Oct 2019
    Location
    Berlin
    Posts
    9
    Thank you Eric, that worked! I wasn't aware you could remove architectures from a fat binary. I will make sure to remember this!

    Gianluca, that solved my issue. I would still recommend delivering xcframeworks or SPM packages for the future (or even better provide Swift source code). If you were in the process of rebuilding Lightstreamer Allegro Presto Vivace 6.1.0 (unified API 2.1.3) as I requested, I would kindly ask you to keep doing it and add support for macOS ARM64. That architecture is not currently available in the Lightstreamer download page (only macOS x86_64).

  7. #17
    Administrator
    Join Date
    Feb 2012
    Location
    Bologna, Italy
    Posts
    101
    Hello dehesa and eric280,

    using your suggestions we were able to build a distribution of the latest version (4.3) of our client library as an XCFramework. Thank you very much for sharing them with us.

    Unfortunately, we encountered difficulties with CocoaPods: its support for XCFrameworks, when distributed as binary packages, seems to be buggy. The pod spec lint command fails with linking errors that should not show up. Since CocoaPods is our package manager of choice, at least for now, and most of our customers use it, we have to wait until its support for XCFrameworks improves.

  8. #18
    Member
    Join Date
    Oct 2019
    Location
    Berlin
    Posts
    9
    That is understandable. The way Lighstreamer is currently being delivered (as dynamic frameworks) and with Eric's suggestion, we can all cover our requirements. I would still ask, if possible, to compile the macOS dynamic framework with "Standard Architectures (64-bit Intel and ARM)". Currently it is only x86-64.

    It is not urgent, since there are no macOS arm64 devices yet. But I expect them to land at the end of this year and we will need to support them. Xcode 12 currently lets you build macOS dynamic frameworks for both x86-64 and arm64 (take a look here or here).

    Regards and thank you, Gianluca, for having taken the time to look at this.

 

 

Similar Threads

  1. Java import - package does not exist
    By UweF in forum General
    Replies: 4
    Last Post: March 2nd, 2016, 06:58 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 03:09 PM.