Skip to content
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

Closed
cjihrig opened this issue Nov 30, 2019 · 6 comments
Closed

Create release and/or tag for snapshots #143

cjihrig opened this issue Nov 30, 2019 · 6 comments

Comments

@cjihrig
Copy link

cjihrig commented Nov 30, 2019

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?

@pchickey
Copy link
Collaborator

pchickey commented Dec 2, 2019

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?

@cjihrig
Copy link
Author

cjihrig commented Dec 2, 2019

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.

@sbc100
Copy link
Member

sbc100 commented Dec 3, 2019

@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.

@cjihrig
Copy link
Author

cjihrig commented Dec 3, 2019

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.

@cjihrig cjihrig closed this as completed Dec 3, 2019
@pchickey
Copy link
Collaborator

pchickey commented Dec 4, 2019

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.

@sbc100
Copy link
Member

sbc100 commented Dec 4, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants