Swift 4.2 + SwiftPM package? (Edit: Swift 5.0)

Sounds good :+1:. I'll create a new 0.3.0 tag from the swift-4.2-branch. It is a few commits ahead of the swift-4.2-RELEASE tag but those commits contain a couple of very important bug fixes.

Edit: This is done https://github.com/apple/swift-package-manager/releases/tag/0.3.0

Thanks.

Even if we don't maintain a stable API, I think it would be good if we "tried" to use the semver as we evolve the API. For example, putting in place practices for annotating PRs that change the API. NIO appears to have an excellent practice in this regard.

Did you update your manifest for the Swift version target you're on?

I don’t understand your question. To whom is it directed? To what manifest does it refer?

In case there was some confusion, this thread is old and the issue which prompted it has long been resolved. The following builds and links fine with Swift 4.2(.1):

// ...
dependencies: [
    .package(
        url: "https://github.com/apple/swift-package-manager",
        .exact(Version(0, 3, 0)))
]
// ...

I don’t see any new release tag in the SwiftPM package to go along with Swift 5.0.

Is 0.3.0 supposed to still work? It is not crashing, but I’m getting some weird test results in my client code. For instance, the loaded package graphs somehow contain no packages.

@Aciid

I haven't tested but I won't be surprised if 0.3.0 is not working anymore with the latest manifest format. Currently, there is no official process for making new (semver) tags and I only do it when someone asks. I'll make a tag that matches Swift 5 release tomorrow. Meanwhile, maybe you can depend on the swift-5.0-branch?

I just tried depending on swift-5.0-RELEASE, but it resulted in build failures in llvmSupport such as undefined symbol: _del_curterm. (That was with the generated Xcode project.) I’ll try a raw package manager build too.

The package manager seems to be capable of building swift-5.0-RELEASE, but Xcode failed to build llvmSupport again on a clean build. This is the error message:

Undefined symbols for architecture x86_64:
  "_del_curterm", referenced from:
      terminalHasColors(int) in Process.o
  "_set_curterm", referenced from:
      terminalHasColors(int) in Process.o
  "_setupterm", referenced from:
      terminalHasColors(int) in Process.o
  "_tigetnum", referenced from:
      terminalHasColors(int) in Process.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

swift-5.0-branch behaves exactly the same as swift-5.0-RELEASE.

@Aciid (not sure if you get notified without being named)

A new semver won’t be particularly helpful until the errors above are dealt with.

I also see no semver tags in swift-llbuild so it probably needs a valid version first in order for SwiftPM to reference it.

I get notified for all things in the Package Manager category :slight_smile:

You need to generate the Xcode project with this xcconfig file: https://github.com/apple/swift-package-manager/blob/master/Examples/package-info/config.xcconfig

Also see:

Won’t that requirement cascade to client packages?

Is there a way to use the new target specific build settings to accomplish it? This makes it sound like the answer is probably no:

Products that contain a target which uses an unsafe flag will be ineligible to act as a dependency for other packages.

It is possible to use the new target specific build settings. We just need to update the llbuild manifest.

I meant from my manifest, but your solution sounds wonderful.

Let me know if there is any way I can help.

I set up some local clones to get a head start on adjusting my own code.

In case it is helpful, these are the changes I have had to make so far:

  1. Branch from swift-5.0-RELEASE in both swift-llbuild and swift-package-manager.

  2. Update swift-llbuild’s manifest tools version to 5.0.

  3. Add linkerSettings: [.linkedLibrary("ncurses")] to swift-llbuild’s llvmSupport target.

  4. Add linkerSettings: [.linkedLibrary("sqlite3")] to swift-llbuild’s llbuildCore and llbuildCoreTests targets.

  5. Tag a semantic version in swift-llbuild.

  6. Point swift-package-manager at swift-llbuild’s new semver.

  7. Tag a semantic version in swift-package-manager.

After that they will compile as dependencies both in the Package Manager and in generated Xcode projects without any tinkering.

I still have to update my own code to account for the API changes before I can run tests to know if everything is actually working properly or if additional steps are still necessary.

There are two things I am still unsure about:

  1. The example xconfig in swift-package-manager also makes reference to a -DSWIFT_PACKAGE C flag. It did not appear to be necessary (yet), but I am unaware of its intended effect.

  2. The Game of Life example in swift-llbuild has an extra -Xlinker -ltinfo flag on Linux and skips the -Xlinker -lncurses used on macOS. I don’t have Swift 5.0 on my Linux machine to test it yet. Since the swift-package-manager repository makes no mention of it, I am wondering how significant it is.

All (my client’s) tests pass on macOS with the above set‐up. I do not know about Linux.

Linux tests pass too with the above adjustments. -ltinfo appears not to be necessary, and -lncurses caused no issues.

Any progress towards tagged semantic versions? Is there any way I can help? @Aciid

I couldn't get to it on Friday but will try to do it very soon.