Add WebAssembly as supported platform for Perl build
There is an initial successful attempt at
- https://github.com/Perl/perl5/compare/blead...haukex:emperl5:emperl_v5.30.0
- https://webperl.zero-g.net/building.html
- https://webperl.zero-g.net
Supporting WebAssembly can help in some interop / legacy scenarios where it would be nice to run existing Perl scripts in a portable / simple / isolated WebAssembly platform - like in browser.
It would be nice if such platform was added to stock perl along with some smoke / github actions ci build tests
The patches to the Perl itself in https://github.com/Perl/perl5/compare/blead...haukex:emperl5:emperl_v5.30.0 are quite minimal and are related to the process termination refactoring, signal handling, and minor fixes to makefiles. It would be awesome to upstream / add similar fixes to upstream - then it would be simpler to at least have a smoke build test
Or please feel free to close / move this issue to another repo, as this suggestion is not about the Perl language itself
I'm not sure this really needs a PPC. I'm pretty sure we would welcome the addition of this as a platform, assuming the changes for it were sensible.
One issue I can see is: can we run tests against it? preferably in a work flow, so we know if we break it.
One issue I can see is: can we run tests against it? preferably in a work flow, so we know if we break it.
Yeah, basic tests can be run, probably some WASI-powered wasm runtime like wasmtime/wasmer could be used, and certainly node can be used for this goal. Almost certain that even shebang / binfmt Linux mechanism can be adapted for this.
In total there are 12 commits in https://github.com/Perl/perl5/compare/blead...haukex:emperl5:emperl_v5.30.0 :
Patches to Perl itself (here probably the noexit and signal patches are the most important ones):
- https://github.com/Perl/perl5/commit/2c6d518732fb8a7b17f8c31e085bab48e82c321c:
Added perlmain_noexit_patch- probably the most important patch here for practical use of WASM-version of perl interpreter, but maybe still not absolutely mandatory to get basic "run script and destroy the interpreter" smoke-like tests - https://github.com/Perl/perl5/commit/e0c5d90b694d4310306767f2e1e8bc2405360c4f:
Disable (almost) all of Perl's signal handling- maybe not needed anymore since Emscripten signal support stubs in https://github.com/emscripten-core/emscripten/pull/20257 - https://github.com/Perl/perl5/commit/4598ea2b3d5493320f798e015b7771a4b6f9258e:
Get Errno to work on Emscripten- here maybe the path toerrno.hcould be promoted to some variable with some extra paths to be defined from Configure step - https://github.com/Perl/perl5/commit/d5271e7c161029ec5f1c236f987e44dd246ca4a3:
Remove use of SOCK_CLOEXEC- here maybedefined(SOCK_CLOEXEC)option could be moved to someconfig.h/ configure variable, then it can be defined via the emscripten platform hints file. Although maybe now not needed, for Emscripten has evolved since 2019 when webperl/emperl was created
Patches to build scripts of Perl:
- https://github.com/Perl/perl5/commit/1ded189233871f5b9ff405f32f2b01a61fd93ecb:
Fix a minor bug with --sysroot in Configure- maybe this can be added upstream without much review - https://github.com/Perl/perl5/commit/b05e740e01b129170661397e523e932a5d0ee65c:
Added emscripten hints file - https://github.com/Perl/perl5/commit/9abeeee8f34c6fe60e5f122c24d70d93663532fe:
Customize Makefile.SH" (here an important thing is that maybe pod-files generation bugs, so the patch removes pod generation)- maybe here an option can be added to the upstream configure/Makefile to disable pod generation altogether, could be useful in the general case as well
The remaining patches are more on interop of JS/Emscripten <> Perl (and are less important for basic functioning):
- https://github.com/Perl/perl5/commit/327812babf4e9be6332919295097573852889fb1:
Added WebPerl module - https://github.com/Perl/perl5/commit/adc38f860132a0fd6e1da62d87ea31feaeca0857:
Added common_preamble.js - https://github.com/Perl/perl5/commit/01a3424114fd102f5be3062d7fdead7d05007d4a:
Added nodeperl_dev files
One issue I can see is: can we run tests against it? preferably in a work flow, so we know if we break it.
Also, regular smoke-test reports would be valuable.
I'm not sure this really needs a PPC. I'm pretty sure we would welcome the addition of this as a platform, assuming the changes for it were sensible.
Yeah, I can't see any reason why anyone would be opposed to it, as long as there's someone actually supporting it (and preferably someone setting up an automatic testing).