Using SPMUtility library in a command line application

Using Swift
1

I am using the SPMUtility library as a command line parser.

      .package(url: "https://github.com/apple/swift-package-manager.git", from: "0.5.0")

So far so good it all works. When I create the - to be distributed - binary using:

swift build --build-path "./.build-macos" -c release

(I am using different build directories for Linux versus macOS) the application is created as expected.

Since Swift-5.0 we should be able to rely on the libraries that are part of the distribution and the created library should be runnable without any further dependencies.

However when I check which dynamic libraries are part of my application:

otool -L .build-macos/release/overrideResolveDotConf
.build-macos/release/overrideResolveDotConf:
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
	xxxxxx/.build-macos/x86_64-apple-macosx/release/libSwiftPM.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1673.126.0)
	@rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 1100.8.255)
	@rpath/libswiftDarwin.dylib (compatibility version 1.0.0, current version 0.0.0)
	@rpath/libswiftDispatch.dylib (compatibility version 1.0.0, current version 0.0.0)
	@rpath/libswiftFoundation.dylib (compatibility version 1.0.0, current version 0.0.0)
	@rpath/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 0.0.0)

I notice that there is a reference to a dynamic library inside the .build-macos directory. (I replaced the leading path with xxxxxx)

So I have a couple of questions:

  1. Is SPMUtility not intended for distribution? If so I have to create my own command line parser I guess. If it can be used I think there should also be a non-dynamic library in the build process.
  2. Is it possible to add some flags to the compilation so that this library actually gets created and or linked into the library?

Any advise would be appreciated.

2

I am using the SPMUtility library as a command line parser.

It is deprecated and has been removed from master. You may want to move to SwiftToolSupport (which is where it was refactored to).

I notice that there is a reference to a dynamic library inside the .build-macos directory.

  1. The linking with absolute paths on macOS was a bug up through Swift 5.1.x. It has been fixed and should be in Swift 5.2. Until then, this is how you can patch the linkage after the fact.

  2. If you don’t want dynamic libraries at all, then you’ll have to restrict your dependency tree to products that aren’t declared as .dynamic. Both SwiftToolSupport and SwiftPM have ‐auto variants for this purpose. For these packages, the .dynamic products are intended for the Swift toolchain, and the -auto variants are intended for consumption as a package dependency. (You cannot mix them in the same dependency graph.)

3

Thanks. I will switch to SwiftToolSupport.