Repository navigation
Remove support for the binaryen interpreter / wasm.js - #7831
Conversation
…ook for emitted files if the command failed
Updates tests to the latest notation changes, and also remove wasm.js (see emscripten-core/emscripten#7831 ) as we'd need to either rebuild it or update it for the new notation as well, and it's not used at this point.
|
Looks fine to me, but I'm not too familiar with the code. |
|
Thanks. Ok, merging, as this unbreaks the waterfall, and was discussed and agreed upon earlier. Would be good if someone can review the code post-merge too though. |
|
cool! |
|
There is |
|
Thinking some more, removing BINARYEN_METHOD would be a big win in removing complexity. Since we haven't used it for debugging for a while, and it's a footgun for it to be misused for dual builds, I'll work to remove it. |
Followup to #7831. This removes BINARYEN_METHOD, which means that if you build with WASM you get wasm, and have no option for an asm.js fallback, and if you build with WASM=0 you get asm.js. This removes and simplifies a bunch of things, so it seems worth it. We do lose the BINARYEN_METHOD=wasm-native,asmjs option which let a single build run either way. That was useful for debugging back when asm.js worked well but not wasm, but those days are far in the past. Another use is to have a single build for both, but it was always a very unoptimized "compromise" build, and not recommended, so removing it avoids a possible footgun for users (if a single build is crucial for people, we should look into a more proper way to do it).
It was useful to bring up wasm support to have a way to interpret wasms, before VMs were up to speed, but at this point we have many VMs with correct behavior. Removing this simplifies our code and speeds up some tests.