Alright then, how about the SONAPWG then? Guess…
2 Likes
do you have an example of something that is a high priority to you, but does not seem to be a high priority to the server committee? that would help make this discussion more concrete
1 Like
There is plenty of things outside Apple that I wish got more momentum and are not server related.
- wasm for example, the tram maintaining that is doing a great work but doesn’t seem that people really knows about it.
- Lately I’ve been looking ant multi-platform game dev and there is things (raylib swift bindings, godot bindings) but it also seems too obscure (sometimes not even compiling)
Not to diminish the value if those efforts, quite the opposite! I’m just trying to point out that yes, the issues being discussed here are not exclusive for ‘server’.
2 Likes
i made the godot bindings, are they not compiling?
I tried some days ago and was not able to make it work. SPM complained about a conflict of dependencies with swift-argument-parser, some "root" package had a version <1 and another had >1. But the error was not clear on which packages had the issue.
In any case I didn't want to derail the conversation, sorry ^^
1 Like
Indeed, I have.
Ignoring all the problems I have during the development (including Foundation's bugs, missing capabilities, and different semantics on NAPs (non-Apple platforms)), what really grieves me is the deployment process.
If it wasn't for the great work of @futurejones, we would not have a proper installation process for Swift. Cutting toolchain tarballs is last century. For many developers (and many users as well), not having proper operating system packages is a major showstopper. What makes this even more problematic is the lack of static compilation, so if you want your binary packages to be consumed by anyone else, you need to depend on a runtime library package.
This is what in my opinion should be a high priority of anyone who wants to increase Swift's popularity.
9 Likes
the release number for swift-argument-parser has doubled since this summer, so it probably just needs a version bump. (feels like i just released it yesterday…)
at the time the plugin was written, package plugins were still very experimental so it depended on master of SwiftPM instead of a tagged release. in the 6 or so months since, that’s probably no longer the case.
in the meantime, can you file an issue on github with your platform and a small test project?
since it wouldn’t be swift if you weren’t holding it wrong, i have learned that swift binaries are just like any other type of binary and they search for libraries in the same directory that the toolchain lived in at the time when the binary was originally compiled.
in this thread i managed to compile with a dynamic standard library on a separate machine from the deployment target, by recreating the directory structure of the target machine.
it’s annoying, but at least we have a solution/workaround for it, which is more than can be said for a lot of other problems in this space
just reiterating. it's amazing that @futurejones does what he does
6 Likes
Imagine how cool it would be if Apple would actually fund such important FOSS efforts, and use the results officially.
2 Likes
seriously, it could really make a whole world of difference.
obligatory retweet:
https://twitter.com/maxdesiatov/status/1451181896784744455?s=20&t=bV34Fm0jGR5ZaFaUPd6i6A
2 Likes
2 Likes
Isn't static compilation supposed to work since a year or so? @fabianfett
If you mean statically linking the Swift stdlib, Dispatch and Foundation*. Yes, it is supposed to work. It was however broken on 5.6 and main up until a few days ago. Announcement post on the forums
Open PRs to fix the issues on main (@Alejandro):
6 Likes
Just adding here for visibility - we have a new Swift Server Community org on GH that solves most of the issues asked here
4 Likes