How to make a module created by Swift Package Manager importable by swift repl

Hi, I've successfully compiled a project using Swift Package Manager, following various tutorials such as:

What I have done so far is just: swift package init --type library, followed by putting in some .swift files, adjusting Package.swift to declare a dependency on another project (namely KDTree), and then swift build, which succeeded.

At this point I see a lot of output files under .build . In particular in .build/x86_64-apple-macosx10.10/debug I see .swiftmodule files for both my project and its dependency KDTree.

How can I now enable the command line repl to import either my own package or classes or KDTree?

A slightly broader question that might shed light on the previous one -- how does the swift repl determine the modules which can be imported?

For the record I am working on macOS 10.13.6 High Sierra. swift --version reports: Apple Swift version 4.2 (swiftlang-1000.11.37.1 clang-1000.11.45.1)

Use swift run --repl. See here for more info.

In general you can use the -I flag to tell the REPL where to find the (compiled) modules you want to be able to import.

Karl, thanks for your reply. I am trying both of the ideas you suggested.

(1a) About swift run --repl, I gather that is a very recently implemented idea (Oct 2018). I guess it's necessary to rebuild swift in order to make that work; is that correct? Is it perhaps only necessary to rebuild swift-package-manager? I did rebuild SPM, and found swift-run in the build artifacts, but that swift-run didn't seem to recognize the --repl option. Perhaps I'm doing something wrong?

(1b) With the goal of rebuilding swift, I have cloned and attempted to rebuild it.

First I tried: utils/build-script --release-debuginfo, but that soon stops with an error, namely: ld: unknown option: --color-diagnostics.

Following a suggestion mentioned in the thread Swift compilation failed, I tried: utils/build-script --release-debuginfo --xcode That runs for longer, but eventually stops with: Configuring incomplete, errors occurred! When I look at the log files, I don't see a clearly marked error, although CMakeError.log does contain the following:

Checking whether the ASM compiler is GNU using "--version" did not match "(GNU assembler)|(GCC)|(Free Software Foundation)":
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/
Checking whether the ASM compiler is Clang using "--version" did not match "(clang version)":
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/

Do I understand from this that Cmake is looking for a known assembler, either GCC or Xcode, and not recognizing the output from as --version? The version string returned is Apple LLVM version 10.0.0 (clang-1000.11.45.2) which doesn't match "(clang version)", therefore Cmake concludes it doesn't have a known assembler?

Assuming that maybe Cmake needs a newer assembler, I'm rebuilding llvm and clang; looks like that will be going on for some time.

(2) About using -I options to tell swift about where to look for modules, that seems to work to some extent. I find that, after swift package init --library in a test directory named Foo, and creating a simple class Bar within that, I can execute

swift -I ./.build/x86_64-apple-macosx10.10/debug\
 -I /Library/Developer/CommandLineTools/usr/lib/swift/macosx/x86_64

At the swift repl, I can now import Foo and it appears to succeed. However, any attempt to access the class Bar fail with error: Couldn't lookup symbols. (For the record, Bar is declared public and all its functions including init are declared public.) E.g.

$ PATH=/usr/bin:$PATH swift -I ./.build/x86_64-apple-macosx10.10/debug -I /Library/Developer/CommandLineTools/usr/lib/swift/macosx/x86_64
Welcome to Apple Swift version 4.2 (swiftlang-1000.11.37.1 clang-1000.11.45.1). Type :help for assistance.
  1> import Foo
  2> Bar.self
error: Couldn't lookup symbols:
  type metadata accessor for Foo.Bar

  2> Bar(text: "hello")
error: Couldn't lookup symbols:
  type metadata accessor for Foo.Bar
  Foo.Bar.__allocating_init(text: Swift.String) -> Foo.Bar

Any ideas about how to help the swift repl find the symbols it wants?

Thanks for any comments, I appreciate your help very much.
Robert Dodier

Hi Robert,

(1) Since you appear to be using a mac, you could just download a pre-built toolchain rather than compiling it yourself.

(2) Ah yes, I think you also need to add -L (and maybe -l) for the linker. I just tried and it doesn't seem to fix it, though, so it's probably better to just stick with the pre-built toolchain and swift run --repl. But in theory those are the options you'd want to play with.

Thanks, Karl. I think I'm getting somewhere now.

About (1), I find that downloading a pre-built toolchain works for me. I downloaded the current snapshot build and installed it to my home directory. I found the swift executable in ~/Library. Then when I execute

/Users/dodier/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2018-12-27-a.xctoolchain/usr/bin/swift run --repl

in my Foo top-level directory, I find that I can import Foo and then say Bar.self or Bar(text: "hi") or whatever, which caused the symbols not found error before. So that's great.

About (2), I don't see any .dylib files created by swift build, so it seems like I can't use the -L and -l options. I see that the preceding swift run --repl does create .dylib files under Foo/.build, while swift build did not. The Package.swift which was created by swift package init --type library does have a library product. I wonder why swift build does not create a .dylib.

Thanks again for your help,

Robert Dodier

Glad it works for you :slight_smile:

FWIW, if you go to Xcode > Settings > Components > Toolchains, you should be able to set that downloaded toolchain as the default, which means you can just use xcrun swift to invoke it.

Beware, though: when building apps for distribution (e.g. for the AppStore), you should (have to?) switch back to the stable toolchain that comes with Xcode.

Terms of Service

Privacy Policy

Cookie Policy