Implement on top of posix API for emscripten - #233
Conversation
|
Also, can you confirm that this change will work with WASI? |
- Add cmake option to turn WASI API on/off - Rename BOOST_STANDALONE_WASM => BOOST_FILESYSTEM_STANDALONE_WASM
|
Apparently I added an alternative mechanism where configuring with I would prefer it to be the other way around though since it's an opt-in from emscripten's side too ( |
|
I have next to zero knowledge about WebAssembly and related ecosystem, so may I ask a few questions for my own education to better understand the PR? I don't quite understand where Emscripten is wrt. WASI. Is WASI using Emscripten as a compiler or is there a different compiler that happen to define If Emscripten is the only compiler, and WASI is just one alternative of the system API, along with what Emscripten provides (what you called "JavaScript API"), which one is the default? Can we assume the default at all? The reason I'm asking is I'd like to know which is the most reasonable default target to compile for. In other words, is the full POSIX API "the norm" or not in WebAssembly world? Or are Emscripten and WASI completely independent and should be considered separate target platforms? |
|
Out of the box you use the Emscripten compiler to generate a set of Wasm/JS files for running in a browser. In addition to building for the web, Emscripten also has an Emscripten tries to use WASI for some of the basic functionality (open/read/write) so if you build using Additionaly the WASI-SDK exists - another compiler/SDK - which builds purely against WASI I'm not to familiar with the current state of WASI but currently Emscripten implements most of the filesystem API through the POSIX functions (getcwd/stat/etc.) |
So, if I understand it right, by default Emscripten targets JavaScript API that supports POSIX. Is it possible to follow this convention in Boost.Filesystem? I.e. when Emscripten is used, by default assume full POSIX compliance, and add a user-defined macro to enable targeting Basically, can we separate Emscripten and WASI-SDK compiler and use different defaults for them? |
Yes
Pretty much what I wanted to do. I will update the PR and ping you when it's done |
When using Emscripten filesystem now links against the POSIX functions
|
Updated it. |
| if(BOOST_FILESYSTEM_DISABLE_BCRYPT) | ||
| target_compile_definitions(boost_filesystem PRIVATE BOOST_FILESYSTEM_DISABLE_BCRYPT) | ||
| endif() | ||
| if(BOOST_FILESYSTEM_DISABLE_EMSCRIPTEN_WASI) |
| set(BOOST_FILESYSTEM_DISABLE_GETRANDOM OFF CACHE BOOL "Disable usage of getrandom API in Boost.Filesystem") | ||
| set(BOOST_FILESYSTEM_DISABLE_ARC4RANDOM OFF CACHE BOOL "Disable usage of arc4random API in Boost.Filesystem") | ||
| set(BOOST_FILESYSTEM_DISABLE_BCRYPT OFF CACHE BOOL "Disable usage of BCrypt API in Boost.Filesystem") | ||
| set(BOOST_FILESYSTEM_EMSCRIPTEN_USE_WASI OFF CACHE BOOL "Use WASI under emscripten in Boost.Filesystem") |
There was a problem hiding this comment.
Shouldn't "Emscripten" start with a capital E?
This allows to enable more POSIX APIs when building with Emscripten by default. Users may switch to WASI API by defining BOOST_FILESYSTEM_EMSCRIPTEN_USE_WASI config macro. Originally implemented in and based on #233.
|
Thanks. I've merged a modified version of this PR. |
2 participants
I want to add a set of defines that correctly implement this library when compiling on top of emscripten.
Some explanation about the checked defines:
TheEMSCRIPTEN_STANDALONE_WASMis defined when you build with-s STANDALONE_WASMso that case should still be ignored/left unimplementedWhen the above is not set and__EMSCRIPTEN__is defined, it's safe to assume that the js library is bundled that implemented the posix filesystem API.I saw #230 , which seems to want to do the same but this should work for both the standalone/emscripten case