wasi-sdk
wasi-sdk copied to clipboard
Ship wasm32-wasi-clang sym links under `bin`?
Using these binaries then wouldn't require a --target
. This is a relatively common pattern for cross compilers and it means you can put wasi-sdk/bin
on the end of your PATH
without shadowing /usr/bin/clang
(which happens if you put it at the start of your PATH
)
Sounds good to me
clang doesn't use target prefixes, as far as I'm aware; that arose from GCC needing to be compiled separately for each target.
There's already been a lot of confusion over what "adding WASI support" should look like in a project. To avoid boxing ourselves in, we'd like people to not add special WASI-specific build rules to lots of projects. Ideally, projects should be able to use their existing build rules as much as possible and target WASI just like any other target. I'm concerned that adding wasm32-wasi-clang
symlinks would encourage people to think of WASI as a special target and just add special build rules for it, rather than filing bugs for things they assume should work.
This does work with clang. Its ends up having the same effect as --target=wasm32-wasi
.
I actually think it more like a normal target if you can just do CC=/path/to/wasi-clang make
rather than CFLAGS=--target=wasm32-wasi CC=/path/to/clang make
. Having to modify both CC and CFLAGS is more hassle that just having to modify CC.
I don''t see why this would make people think of it any differently. arm-linux-gcc is still gcc right?.
Ah, I didn't know that clang picked up a default target from argv[0]. TIL. I'd be curious to know how people use that. Would one install wasm32-wasi-clang in the same bin directory as one installs clang? If so, then we're still potentially shadowing the system clang. Would one put wasm32-wasi-clang in a separate bin directory, so people can decide whether to put /opt/wasi-sdk/bin or /opt/wasi-sdk/wasm32-wasi-bin (or whatever) in their PATH?
Also, if you're using wasi-sdk, the default is already wasm32-wasi, so you don't need to pass --target. CC=/opt/wasi-sdk/bin/clang make
just works.
I was imagining one could put /opt/wasi-sdk/bin
at the end of your PATH then you can call system clang via clang
(since it will see the system one, e.g. /usr/bin/clang, first) and still access wasi clang via wasm32-wasi-clang.
TIL that wasi-sdk clang doesn't need --target! Thats pretty cool I guess and maybe makes this idea less useful (but not useless).
However it might also be also a little confusing since I would imagine that most clang
builds default to not cross compiling and require --target
to trigger the cross compiler. I've not seen enough clang corss tools to know (would be interested to know what android and fuchia do for bare clang
)
@sbc100, what do you think, is this still something we should think about doing?
I don't think this is worth it given that we have set the default wasm32-wasi already