Add WebAssembly as supported platform for Perl build

[vadimkantorov]

There is an initial successful attempt at

• Perl/perl5@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 Perl/perl5@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

[vadimkantorov]

Or please feel free to close / move this issue to another repo, as this suggestion is not about the Perl language itself

[haarg]

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.

[tonycoz]

One issue I can see is: can we run tests against it? preferably in a work flow, so we know if we break it.

[vadimkantorov]

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.

[vadimkantorov]

In total there are 12 commits in Perl/perl5@blead...haukex:emperl5:emperl_v5.30.0 :

Patches to Perl itself (here probably the noexit and signal patches are the most important ones):

• Perl/perl5@2c6d518: 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
• Perl/perl5@e0c5d90: Disable (almost) all of Perl's signal handling - maybe not needed anymore since Emscripten signal support stubs in Implement default signal handlers emscripten-core/emscripten#20257
• Perl/perl5@4598ea2: Get Errno to work on Emscripten - here maybe the path to errno.h could be promoted to some variable with some extra paths to be defined from Configure step
• Perl/perl5@d5271e7: Remove use of SOCK_CLOEXEC - here maybe defined(SOCK_CLOEXEC) option could be moved to some config.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:

• Perl/perl5@1ded189: Fix a minor bug with --sysroot in Configure - maybe this can be added upstream without much review
• Perl/perl5@b05e740: Added emscripten hints file
• Perl/perl5@9abeeee: 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):

• Perl/perl5@327812b: Added WebPerl module
• Perl/perl5@adc38f8: Added common_preamble.js
• Perl/perl5@01a3424: Added nodeperl_dev files

[jkeenan]

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.

[Leont]

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).