Add 'wasm32-unknown' to known targets #90223
Conversation
dfordivam
requested review from
Ericson2314,
matthewbauer and
nbp
as code owners
| @@ -71,6 +73,7 @@ in { | |||
| wasi = filterDoubles predicates.isWasi; | |||
| windows = filterDoubles predicates.isWindows; | |||
| genode = filterDoubles predicates.isGenode; | |||
| wasm = filterDoubles predicates.isWasm; | |||
There was a problem hiding this comment.
This should go up above with the CPU arches
| @@ -342,6 +343,7 @@ rec { | |||
| uclibceabihf = { float = "soft"; }; | |||
| uclibceabi = { float = "hard"; }; | |||
| uclibc = {}; | |||
| wasm = {}; | |||
There was a problem hiding this comment.
I don't think we need this? this would be for e.g. wasm32-unknown-none-wasm.
| @@ -280,6 +280,7 @@ rec { | |||
| windows = { execFormat = pe; families = { }; }; | |||
| ghcjs = { execFormat = unknown; families = { }; }; | |||
| genode = { execFormat = elf; families = { }; }; | |||
| unknown = { execFormat = unknown; families = { }; }; | |||
There was a problem hiding this comment.
I am a bit uncomfortable adding unknown as it's not actually an OS (kernel should be renamed OS). But yes there doesn't seem to be many good options, maybe we could even temporarily call it webghc, just like the ghcjs up above.
I would like to use to use browser, cause at the end of the day regardless of what sort of libc you get there is the externally implemented wasm interfaces that seem to be the moral equivalent of the syscalls---interfaces into the hosting system (OS) which is outsides the program's own control.
There was a problem hiding this comment.
I did some study of this, but did not find very convincing solution to what the OS should be called.
Regarding the unknown OS though, it has been widely used in the wasm cross-compilation target.
In fact it is present in the code mentioned at the top of this file http://llvm.org/doxygen/Triple_8cpp_source.html
case UnknownOS: return "unknown";
(Also there is no none option).
Nevertheless at this stage getting this correct is not even that important. If wasm32-unknown-none-musl is the one which works without adding unknown to the OS list, I am ok with it. Only when the changes are being upstreamed to ghc this will have to be fixed properly.
|
Closing this as there is no consensus on the appropriate target, and moreover the target used by WebGHC might change in future, especially if it starts using wasi. |
Motivation for this change
This adds the support of
wasm32-unknown/wasm32-unknown-unknownlike targets.WebGHC uses the
wasm32-unknown-unknown-wasmtarget for the web-assembly cross compilation support for GHC/Haskell. But this can be used by any other tool chain doing web-assembly cross compilation.It is necessary to upstream this as it is not possible to make it work using overlays. (let me know if I am wrong)
The
wasmis meant to be different from thewasi/wasm32-unknown-wasi/wasm32-wasitarget (already present in nixpkgs), as it is a general web-assembly target, and is not tied to the wasi specification.wasiis an already supported cross-compilation target in nixpkgs. But for WebGHC it cannot be used right now, as it is somewhat constrained interface. In future WebGHC might also move to using thewasiinterface, but for the time being it uses a custommuslfork, and therefore chose to use a more generalwasm32-unknowntarget for itself.This is the first of the two PRs needed for upstreaming all the nixpkgs changes for wasm cross compilation support of WebGHC.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)