Sounds good . 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.
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.
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):
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.
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)
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:
Branch from swift-5.0-RELEASE in both swift-llbuild and swift-package-manager.
Update swift-llbuild’s manifest tools version to 5.0.
Add linkerSettings: [.linkedLibrary("ncurses")] to swift-llbuild’s llvmSupport target.
Add linkerSettings: [.linkedLibrary("sqlite3")] to swift-llbuild’s llbuildCore and llbuildCoreTests targets.
Tag a semantic version in swift-llbuild.
Point swift-package-manager at swift-llbuild’s new semver.
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:
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.
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.