This is just an account of my first experiences with Emscripten and this is empatically not a tutorial for ,or review of emscripten.
Smooth sailing period
So I started to make a small test-game with SDL2 and thought I’d try to compile with emscripten. So I downloaded the Windows SDK and since I didn’t have a CMake or other unixy compatible Makefile for the project yet I just made a unit-build like *.cpp that includes all *.cpp files to compile.
Just doing the “em++ -I../src unity.cpp” got surprisingly far, it had some issues with some SDL Functions though. I imagine it to be because it presumes SDL1.2 instead of SDL2. So searched for whether it SDL2 was available for emscripten as well.
Some bumps in the road
It was, in source form. After downloading the source my problems started. The build-instructions for SDL-emscripten told me to use “emconfigure ./configure […]” which didn’t work under Windows since it couldn’t find any executable named “configure”.
Alright, so that was a no-go. But there was another suggestion to do the configuration with “emconfigure cmake”. This failed for me because I accidentally tried to execute that inside the source tree, which just gave me an error about it. Since I didn’t want to hunt for all the configuration files to delete, I just unzipped the SDL source tree again and corrected my error.
While CMake now generated project files successfully it was sadly VS2013 project files, which naturally don’t work at all. So I had to switch the CMake generator to “MSYS Makefiles” to hopefully get something useful. CMake again happily obliged to generate Makefiles. Now just to open my MSYS shell and type “make” right? Not quite, the *.bat files to set up the environment variables to get emscripten to run didn’t work in bash for obvious reasons and the *.sh file that was in the emscripten directory just called some other *.sh files that were nowhere to be found. Well that’s enough of that, I got the message. Windows isn’t really suited to run these tools that are primarily designed for UNIX like environments.
“Well, I’ll just try my Linux Laptop then” I thought to myself a little spitefully. There downloading the SDK files wasn’t an issue either, but the installation entails compiling LLVM clang which took a little while. In fact such a while that I started writing this blog post in the meantime.
Back on track?
“Alright, so this should be easier” I told myself. I was not quite without issues though. For some reason it tried to call nodejs by “node” but my Ubuntu distro only had it under the name “nodejs” so I had to install a legacy package that created a symlink (not that I couldn’t make the symlink myself, but this way it gets cleaned up if I ever remove nodejs).
Getting “something” to compile was taken care of after that. It was just linking that was a problem now. Curiously linker errors are just warnings with emscripten (presumably because you can patch those in at runtime in Javascript). It took me quite a while to figure out that using “em++” to link didn’t work. So I had to compile with “em++” and link that resulting obj-file with “emcc” to get it to cooperate.
That was a good waste of a Saturday.