Open diamondburned opened 6 months ago
Thanks, I'm fine with supporting tinygo builds and adding it to CI.
I'm not super pumped about adding tinygo build tags, though. Ideally, tags like cgo
or purego
would be enough for the code on master to already be portable. For example, with either CGO_ENABLED=0
or -tags=purego
, os/user.Lookup
on Linux should be a stub that returns nothing, why is that not enough for Tinygo?
https://tinygo.org/docs/reference/lang-support/stdlib/#osuser does show a failure, but that seems like a bug that should be tracked/fixed upstream.
https://tinygo.org/docs/reference/lang-support/stdlib/#osuser does show a failure, but that seems like a bug that should be tracked/fixed upstream.
I made https://github.com/tinygo-org/tinygo/pull/4278 to address this.
With https://github.com/tinygo-org/tinygo/pull/4278 merged a while back, I assume we can now get rid of the build tags here?
I got rid of a few stubs, but I still have to stub os.SameFile
for Tinygo + WASM to work :(
That's very odd. Upstream Go doesn't have SameFile behind any build tags, even though they support js/wasm. It seems to me like TinyGo should at the very least publish the stub themselves; the APIs should compile on all platforms, even if all they do is always fail on the unsupported platforms.
This PR contains commits that allow
mvdan.cc/sh/v3
to be built using Tinygo. The commit messages will contain more information.