[WIP] Add CMake build system

[loganek]

This is a work-in-progress PR and still require a few actions. I open the PR to get early feedback. Some of the changes are clone from the other attempt of migrating this repository to CMake build system: #154. One major difference between this change and the previous one is that I'm using install target to create sysroot; I find this to be a bit more natural than specifying destination for every target.

I tested the changes by diff-ing generated install directory with the sysroot generated by Makefile. I also compiled and ran a few apps on WAMR runtime.

• [ ] remove Makefile
• [ ] update CI files
• [ ] update README file

Resolves #322

[sbc100]

I know you mention some rational in #322, but I'm curious what you personal primary motivation is for wanting to make this change? I guess better native windows support is the big one? Without needing to setup something like mingw?

I personally find cmake syntax and semantics pretty confusing (more so than the relative simplicity of a Makefile), but I get that its personal preference.

This does seem to make some things more complex. For example, it looks like it takes roughly twice as many lines of code to implement. We would also be adding a python dependency. I'm generally a fan of python over shell scripts for this kind of thing but others might feel differently.

[abrown]

I personally find cmake syntax and semantics pretty confusing

I'm also not sold on replacing make with cmake. make is available on Windows in various ways: WSL, MinGW, and Visual Studio. I'm not opposed to replacing it, but I feel cmake would have to offer something better than what currently exists. Also, I'm a bit concerned that people working on the project may be familiar with a Makefile but would be slower to hack on a CMakeLists.txt (as @sunfishcode mentions in #322). Just some thoughts...

[penzn]

In my opinion, it provides more watertight ways to ensure you have the pieces you need, also it has "first class types" for sub-targets like libraries, including dependence detection, this reduces risk of mistyping or having parts of the build go out of sync. It isn't a silver bullet, though.

[loganek]

I know you mention some rational in https://github.com/WebAssembly/wasi-libc/issues/322, but I'm curious what you personal primary motivation is for wanting to make this change?

Pretty much what @penzn already mentioned but also having experience with both Makefile and CMake, I find both learning CMake and maintaining CMake project easier. I also think Makefile has a steeper learning curve than CMake but that may be because I ~~learned~~ used Makefile first.

This does seem to make some things more complex. For example, it looks like it takes roughly twice as many lines of code to implement.

I wouldn't use number of lines as a metric for complexity. If needed, I could probably optimize (most likely at a cost of readability, although I didn't look into it).

We would also be adding a python dependency. I'm generally a fan of python over shell scripts for this kind of thing but others might feel differently.

I don't think this is relevant to Makefile vs CMake discussion. They both can run shell and python scripts; I copied it (and slightly modified) from previous PR because I found it more readable.

Also, I'm a bit concerned that people working on the project may be familiar with a Makefile but would be slower to hack on a CMakeLists.txt (as @sunfishcode mentions in #322). Just some thoughts...

What I found is that creating a CMake project from scratch requires some knowledge, but most of the modifications don't often require looking into documentation, as you can do most of what you need based on already written code (I guess just like Makefile)

[loganek]

Could you add some instructions (maybe as a mod to the README) so I can try it out? I've love to give it go. Does this setup support out-of-tree building?

I can definitely update the README file; meanwhile, here's a command you can use:

# assume you're in wasi-libc
cd .. # go up; we'll do out-of-tree build
mkdir wasi-libc-build && cd wasi-libc-build
# configure the project
cmake \
  -DCMAKE_C_COMPILER=/usr/bin/clang-15 \ # optional, cmake will try to find a default one
 -DCMAKE_BUILD_TYPE=Release \ # optimized build; other options: Debug, RelWithDebInfo
 -DTHREAD_MODEL=posix \ # thread model: single
 -DCMAKE_INSTALL_PREFIX=../cmake-install \ # where to install the sysroot
 -G Ninja \ # generator, default on Linux is most likely Unix Makefiles
 ../wasi-libc # path to source directory
ninja install # build and install

[sunfishcode]

One concrete advantage of moving to CMake is that the current wasi-libc Makefile doesn't do dependency management correctly, so we effectively don't have incremental builds right now.

[loganek]

Yes, incremental build is a huge benefit, but I never listed it as a benefit because I'm not sure how hard is it to implement it for the existing Makefile.