Open jeswr opened 1 year ago
I don't know that much about the WASM build. AFAIK though, we build swipl.js/wasm such that it uses the native filesystem, which you can see if you run node src/swipl.js
in the build directory. We need such a version to perform the Prolog build steps, producing home/boot.prc
and the various .qlf
(Quick Load File) files.
So does this mean an update to the cmake file is required?
I don't know what to think about swipl.js/wasm
. I am inclined to consider it just an intermediate build product. We could also distribute it along with a the libraries as a file hierarchy, so you get something similar to the normal distributions that consist of the executable and the libraries. Wasn't it true that swipl-web.js and the bundles also run under Node? If that is true the only thing wrong seems the misleading "web" in the name?
Currently there is a PR open in npm-swipl-wasm to properly use
swipl.js
for node rather than copyingswipl-web.js
toswipl.js
(see https://github.com/SWI-Prolog/npm-swipl-wasm/pull/101).As can be seen in the CI; this is currently failing because there is no
swipl.wasm
orswipl.data
available; and it would appear that they are not being generated by https://github.com/SWI-Prolog/swipl-devel/blob/master/cmake/EmscriptenTargets.cmake in the way that https://github.com/SWI-Prolog/swipl-devel/blob/a5116396306d5107bb9ba6c319a239f9fc9f9733/cmake/EmscriptenTargets.cmake#L50-L61 is.So my question is; are
swipl.wasm
andswipl.data
going to be the same as theswipl-web.wasm
andswipl-web.data
; in which case we can just take a short term solution of duplicating those files; or patching the lookup paths in the generated.js
files. Or do we need to generate distinctswipl.wasm
andswipl.data
fromEmscriptenTargets.cmake
- in which case I'd ask someone else with more expertise to take it on as I am going to be time poor for the next couple of months.