polyfill-prototype-1
polyfill-prototype-1 copied to clipboard
lukewagner
first attempt at cmake build system
review? @lukewagner
this builds the two c++ executables, but doesn't build the emscriptenized load-wasm-worker.js file or remove anything from the Makefile.
Do you expect you'll add the emscriptenized load-wasm-worker.js feature eventually? (In other words, is this the first step toward implementing the comment in the first line of https://github.com/WebAssembly/polyfill-prototype-1/blob/master/Makefile ?)
Not sure about the js exectubale regarding best practices of having compiler specific build targets. I'll have to do some research, but I think it's doable. @juj probably knows.
Sure, it's possible to have CMake target .js or .html output files. See the CMake tests in Emscripten tests/ directory. Note that it is not a project-specific property, but Emscripten is a platform to target, just like Windows, Linux or OS X. That means that one CMakeLists.txt file can't contain two projects that would target different platforms, e.g. one that would target native, and another that would target JS, but the choice of which one to compile for is done at command line by choosing the appropriate target toolchain file (for Emscripten, that's running with emcmake cmake xxx instead of just cmake xxx)
so basically, the cmake build script would have to be run twice; once to build the C++ code, and once to build the JS code, possibly removing the cmake cache in between? Does that sound correct @juj?
Yes, or set it to build to two different directories, so they can each have their own cache files and directory structures.
or set it to build to two different directories
So I would have to move the source files into their own directories each with their own CMakeLists.txt?
No, there's no need to move anything. CMake is not restricted to making builds to the root directory of the project, but good CMake practices employ what they call "out-of-source" builds, see http://www.cmake.org/Wiki/CMake_FAQ#What_is_an_.22out-of-source.22_build.3F . This is intended to exactly cater to the case when one wants to simultaneously keep builds of the same project with multiple different configurations (e.g. different target platforms, different build options, like debug vs release, or simd enabled vs not, or anything else custom).
On vacation atm, but when everything works, @sunfishcode feel free to do the merge.
