Build system for multi-part Emscripten projects

Question

I've been using Make for my Emscripten project, but am wanting to move to another build system. I've tried a few, but haven't found any that seems ideal for it yet.

Ideal criteria:

• Out of source builds
  • not essential, but would be nicer than all the crud in my current Make setup
• Low boilerplate setup
  • I started trying Google's gn, but it looks like you need several other .gn files before it will even look at your BUILD.gn
• Understands C so separate .o targets don't need to be specified
  • Meson had this which I liked
• Syntax that helps you DRY
  • My project has one static library and four executables which depend on it (in the future there will probably be more.) Each executable will share many arguments, but also have some modified ones, and some completely unique ones. A build system that has support for dictionaries, or functions with named arguments would be helpful.
• Flexibility for complicated linked arguments, including depending on non-C files
  • This is where Meson's big weakness for Emscripten projects was. To tell the emcc linker to include Javascript/JSON files I had to use Meson's "configure" command to copy them to the build directory, after which it could be used in a linker argument. But this seems like a hack, and the docs were really unclear about whether or not it would continue watching for changes to those files. A build system that is designed for additional dependencies at the linker stage would be better.

The last one is the most important, and seems like the biggest complication when moving away from an in-source make setup.

Any recommendations would be much appreciated, especially if you have used it with Emscripten or another compiler with lots of linker arguments.

Answer 1

I ended up settling on CMake. I had previously tried it and dismissed it as being too complicated, but that was mostly because I was trying to build my project using CMake 'submodules' (I'm not exactly sure of the terminology.) I now specify all the targets in the main CMakeLists.txt and it's relatively straightforward.

How CMake meets my criteria:

• Out of source builds

  • CMake is great with this, and even with semi-in-source builds that are supposedly dangerous (ie, building to a build/ folder in your main source folder.

• Low boilerplate setup

  • With the Emscripten provided emcmake and emmake wrapper scripts you don't have to manually set up the compiler to know about Emscripten and can just get straight to defining your target executables.

• Understands C so separate .o targets don't need to be specified

  • CMake is great for this. Just include the .c or .cpp sources in your targets.

• Syntax that helps you DRY

  • Functions are easy to define and use in CMake. CMake also has support for named function arguments, although you need to call cmake_parse_arguments manually in the function body. It's not as good as in other languages, but it's not a big burden.

• Flexibility for complicated linked arguments, including depending on non-C files

  • The big advantage of CMake for Emscripten is that Emscripten gives you helper functions for specifying JS library files, and its --pre and --post options. If you want more than that however, such as the options that require a JSON file you'll need to copy the process its functions follow, and that's quite involved. CMake also does not make it simple to specify post-processing scripts to run, you need to specify two types of targets in order to get the file-changed triggers to work. You can see in my functions file how I handled both of these.

    But these are both relatively minor issues, and many Emscripten projects won't need them. In fact I've stopped needing them in my project so my current functions file is really short and simple now.