objecthub / swift-lispkit

Interpreter framework for Lisp-based extension and scripting languages on macOS and iOS. LispKit is based on the R7RS standard for Scheme. Its compiler generates bytecode for a virtual machine. LispKit is fully implemented in Swift 5.
https://lisppad.app
Apache License 2.0
383 stars 14 forks source link

Failed to Add as Package Dependency #26

Open infiniteNIL opened 2 weeks ago

infiniteNIL commented 2 weeks ago

I'm trying to bring swift-lispkit into my project as package dependency and I get the following

Screenshot 2024-08-28 at 5 09 49 PM
objecthub commented 2 weeks ago

I would be happy to help fix this, but I would need more information: is your project an Xcode project? Do you use the Swift package manager? How did you specify the dependency on LispKit?

infiniteNIL commented 2 weeks ago

Yes, it's an Xcode project. I'm on Xcode 15.4. Yes, I use SPM. I tried various ways of specifying the dependency. I tried specifying 2.4 up to next major. I tried specifying using the major branch. I think I also tried up to next minor.

Only specifying the major branch would bring in the dependency ok, but then it wouldn't build, I think because it was missing a dependency. I'd have to try it again and get the exact message.

infiniteNIL commented 2 weeks ago

When I bring in master, it downloads fine. When I build, I get the following error:

/Users/rod/Library/Developer/Xcode/DerivedData/Numerology-gszdfffcpsmekidjhmrnpcomoxze/SourcePackages/checkouts/swift-lispkit/Sources/LispKit/Data/Serialization.swift:24:8 No such module 'CBORCoding'

objecthub commented 2 weeks ago

First of all, the build issue you are experiencing are totally my fault. I am using Xcode as my primary development tool and I update the SPM package definition only when I create a release. I have fixed that now with my latest commit.

There are basically two ways to integrate LispKit: 1) for macOS and iOS applications, the recommended approach is to use Carthage. 2) for command-line applications, it's easiest to use SPM

Approach 1) relies on dynamic linking: Carthage builds a LispKit framework bundle which is then included under "Frameworks and Libraries" in your Xcode project target (under "General"). The bundle includes not only the binary, but also all assets needed by the full LispKit environment (like all Scheme source code, example code, tests, etc.). You don't have to worry about those assets at all as the default LispKit setup will refer to them by default. Here's how your target could look like in Xcode (you can ignore the LispKitTools.framework, unless you want to build an extended REPL):

Screenshot 2024-08-30 at 23 55 52

Approach 2) relies on static linking via SPM. I haven't tried doing that in Xcode, but it does work well if a command-line application is built via swift build in the terminal. This requires that all the assets are stored and looked up in a separate directory.

I am maintaining a demo integration called NumericalScheme which showcases both approaches: It comes with an Xcode project that includes LispKit via Carthage and it also defines an SPM-based integration for executing the contained command-line application (without using Carthage). I suggest you have a look at this project and follow the instructions in the README.

If you get stuck somewhere, let me know, and I'll try to do my best to help.

(Since about 2 years it is technically possible to build modules via SPM, which basically lets you bundle assets with the code. But given LispKit has thousands of such files, I would need to find a way to automate the Package.swift file generation somehow, or copy the whole asset directory as a whole and patch in a few changes. I have not explored this approach)

infiniteNIL commented 2 weeks ago

Thanks. I'm building an app, so I'll try the Carthage approach.