You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CMake is fine. @waywardmonkeys your changes don't seem to be public yet. Can you push them? I would like to take a look as I'm also interested in working on this.
build.sh is not in sync with CMake and fails in several ways. Even after making sure that I compile the same source files as CMake, check.py fails because the support library is not built.
Question is, should we fix build.sh or just drop it all together?
Yeah, it's getting worse. I just pushed a commit to move build.sh to use cmake for everything that it can, which is everything but wasm.js. Hopefully we can figure out the wasm.js bit (tricky part is calling emcc, and not the system compiler), and remove build.sh entirely.
This is mostly done, but we still have build-js.sh for building the JS parts. Would be nice if that could be done in cmake as well, but it means invoking out to call a different compiler (emcc) so maybe not. If not, we can close this.
If build-js.sh stays as simple as it is, then unlikely to be worth the effort of trying to have multiple toolchains in a single build system configuration. This is especially true since we don't really need to have support for random users running it on a variety of OSes. I'd say we can call this issue fixed since we have CMake and of course update it as needed.
With sexpr-wasm, I have a neat trick where I have a top-level Makefile drive the CMake build underneath. That way you can have different toolchain configurations easily accessible. Currently I support a full matrix of {gcc, gcc-i686, clang, emscripten, gcc w/ AFL fuzz} * {debug, release} * {msan, lsan, asan, ubsan}.
Activity
waywardmonkeys commentedon Dec 18, 2015
I've got a start on this in cmake ... I'll submit a pull request shortly. It isn't complete, but it is a start.
svenstaro commentedon Dec 19, 2015
CMake is fine. @waywardmonkeys your changes don't seem to be public yet. Can you push them? I would like to take a look as I'm also interested in working on this.
Initial start on CMakeLists.txt.
kripken commentedon Dec 19, 2015
After @WaywardMonkey's first pull and some tweaks, cmake mostly works. The main missing piece is it doesn't invoke emcc to build wasm.js yet.
mbebenita commentedon Jan 6, 2016
build.shis not in sync with CMake and fails in several ways. Even after making sure that I compile the same source files as CMake,check.pyfails because thesupportlibrary is not built.Question is, should we fix
build.shor just drop it all together?kripken commentedon Jan 6, 2016
Yeah, it's getting worse. I just pushed a commit to move build.sh to use cmake for everything that it can, which is everything but wasm.js. Hopefully we can figure out the wasm.js bit (tricky part is calling emcc, and not the system compiler), and remove build.sh entirely.
kripken commentedon Jun 28, 2016
This is mostly done, but we still have
build-js.shfor building the JS parts. Would be nice if that could be done in cmake as well, but it means invoking out to call a different compiler (emcc) so maybe not. If not, we can close this.dschuff commentedon Jul 7, 2016
If
build-js.shstays as simple as it is, then unlikely to be worth the effort of trying to have multiple toolchains in a single build system configuration. This is especially true since we don't really need to have support for random users running it on a variety of OSes. I'd say we can call this issue fixed since we have CMake and of course update it as needed.binji commentedon Jul 7, 2016
With sexpr-wasm, I have a neat trick where I have a top-level Makefile drive the CMake build underneath. That way you can have different toolchain configurations easily accessible. Currently I support a full matrix of {gcc, gcc-i686, clang, emscripten, gcc w/ AFL fuzz} * {debug, release} * {msan, lsan, asan, ubsan}.
[EH] Change catch_all's opcode
[EH] Change catch_all's opcode