-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create release and/or tag for snapshots #143
Comments
Yes, we could start tagging releases, but historically there are many releases of this library (as a component of https://github.com/CraneStation/wasi-sdk) that map to a single snapshot. Those releases have included a full build of clang and rt.builtins, but in the most recent (https://github.com/CraneStation/wasi-sdk/releases/tag/wasi-sdk-8) we added a distribution of just the sysroot, which contains the wasi-libc build and rt.builtins without clang. Does using the wasi-sdk releases work for your use case? If not, does adding tags here that correspond to the wasi-sdk releases work? |
I'm not sure that mapping to wasi-sdk releases would work since it's possible to use WASI with wasi-libc, and no wasi-sdk. In that case, it would be nice to be able to say "try with snapshot1" for example. Until WASI completely stabilizes, I can picture users running into version compatibility issues between wasi-libc and whatever the runtime implements. |
@cjihrig are you currently using wasi-libc without wasi-sdk? For most end users, if they want to "try with snapshot1" then for sure the best/fastest way for them to do that would be use a specific wasi-sdk version. Maybe your use case is different though? Can you explain why you don't (or can't) use wasi-sdk? For one thing the sdk has pre-built binaries there so trying out different versions is much easier and faster as you don't need to re-compile the whole libc. |
Yes, I've been using wasi-libc directly. There is nothing about my use case that prevents me from using wasi-sdk, I just found it simple enough to clone wasi-libc, compile it, and point clang at it. I guess that is not the recommended way of doing things, so I'll close this. |
There's no reason not to follow your workflow, its mostly that none of the current maintainers follow it, so we haven't done anything to make it easy to track versions. If the wasi-sdk path works for you, that is the path of least resistance for us. But if there is any issue with it, or you just would rather keep your old workflow, we can add a release cycle to this repo that works for your needs. |
Sorry I didn't mean to completely shut this down. I'm happy for us to tag versions here too. If it made sense we could even provide binaries of just libc.. but then you normally want compiler-rt and libc++ too in order to actually build stuff. |
I think it would be useful to have releases/tags for each snapshot. There is currently one release labeled v0.1-alpha from back in March. Can releases for snapshot0 and snapshot1 be added?
The text was updated successfully, but these errors were encountered: