Migrate the `Makefile` to CMake #685

alexcrichton · 2025-11-21T20:00:07Z

This commit migrates wasi-libc's build system from a make-based system to CMake. This is a complete rewrite of the build system which culminates in the deletion of the current Makefile and a few supporting scripts and files.

The rationale/reasons for this are similar to WebAssembly/wasi-sdk#429, namely:

Building a correct and robust build system in make is not easy. There are many times I've found myself in a situation where I need to blow away the entire build directory between builds. Much of the this this bottoms out in subtle behavior like "this file was renamed, but didn't get deleted in the archive" or subtle things like that. CMake is responsible for handling these by default and, in general, is probably going to be more correct than what we write.
Out-of-tree builds are now supported.
Customizing CFLAGS is now supported via standard mechanisms. Previously EXTRA_CFLAGS was required since using CFLAGS could break the build.
It's easier to move more logic into CMake, such as downloading compiler-rt, than it is to codify it all in makefiles.
Platform portability is generally easier in CMake than make. Building on Windows shouldn't require a full GNU-like environment, for example.
Tests now properly rebuild themselves when wasi-libc changes.
It's easier to customize high-level options, like "enable SIMD", in CMake than it is in Makefiles. This can be documented as a single option to pass where that option affects the build, flags, etc.

Personally I'm not a fan of CMake, but I'm more of a fan of it than Makefiles, hence my desire to switch. I want to make this repository easier to build, configure, and change over time. This will also make it easier to integrate this all into wasi-sdk where everything is CMake-based over there as well.

I am not a CMake expert, nor am I necessarily an expert in the previous Makefiles. I've done my best here, but I'm happy to change things if someone who knows more about CMake than I (which is a lot of folks) recommends doing so. I'm also happy to adjust the libc build as desired too.

Closes #46
Closes #156
Closes #259
Closes #322
Closes #330
Closes #514
Closes #551
Closes #605

This commit migrates wasi-libc's build system from a `make`-based system to CMake. This is a complete rewrite of the build system which culminates in the deletion of the current `Makefile` and a few supporting scripts and files. The rationale/reasons for this are similar to WebAssembly/wasi-sdk#429, namely: * Building a correct and robust build system in `make` is not easy. There are many times I've found myself in a situation where I need to blow away the entire build directory between builds. Much of the this this bottoms out in subtle behavior like "this file was renamed, but didn't get deleted in the archive" or subtle things like that. CMake is responsible for handling these by default and, in general, is probably going to be more correct than what we write. * Out-of-tree builds are now supported. * Customizing CFLAGS is now supported via standard mechanisms. Previously `EXTRA_CFLAGS` was required since using `CFLAGS` could break the build. * It's easier to move more logic into CMake, such as downloading compiler-rt, than it is to codify it all in makefiles. * Platform portability is generally easier in CMake than make. Building on Windows shouldn't require a full GNU-like environment, for example. * Tests now properly rebuild themselves when wasi-libc changes. * It's easier to customize high-level options, like "enable SIMD", in CMake than it is in Makefiles. This can be documented as a single option to pass where that option affects the build, flags, etc. Personally I'm not a fan of CMake, but I'm more of a fan of it than Makefiles, hence my desire to switch. I want to make this repository easier to build, configure, and change over time. This will also make it easier to integrate this all into wasi-sdk where everything is CMake-based over there as well. I am not a CMake expert, nor am I necessarily an expert in the previous Makefiles. I've done my best here, but I'm happy to change things if someone who knows more about CMake than I (which is a lot of folks) recommends doing so. I'm also happy to adjust the libc build as desired too. Closes WebAssembly#46 Closes WebAssembly#156 Closes WebAssembly#295 Closes WebAssembly#322 Closes WebAssembly#330 Closes WebAssembly#514 Closes WebAssembly#605

alexcrichton · 2025-11-21T21:40:19Z

To verify this change I've built the sysroot with the old makefile and this PR. The order of files in libc.a, and thus linked into libc.so, is different meaning that libc.so is not byte-equivalent. What I did do, however, was unpack libc.a in both sysroots and ensure that each individual file is the same. The resulting diff (for wasm32-wasip1) is:

Only in make: "/home/alex/code/libc-diff/../wasi-libc/sysroot/include/wasm32-wasip1/wasi/wasip2.h"
Only in make archive "lib/wasm32-wasip1/libc.a": "wasip2_stdio"
Only in make archive "lib/wasm32-wasip1/libc.a": "wasip2_tcp"
Only in make archive "lib/wasm32-wasip1/libc.a": "wasip2_udp"
Only in make archive "lib/wasm32-wasip1/libc.a": "wasip2_file_utils"
Only in make archive "lib/wasm32-wasip1/libc.a": "wasip2_file"
Different: "include/wasm32-wasip1/__wasi_snapshot.h"

This is expected in that I removed some wasip2 bits from the wasip1 archives/sysroot (e.g. the header and wasip2-only objects). The __wasi_snapshot.h is then an intentional change in this PR (a file generated by CMake as opposed to handwritten via shell).

Basically I've double-checked that, with the right compile flags, the set of objects produced is the same and they all have the exact same contents as well. Artifacts will differ slightly as items are reordered, however.

I'll also note that CMake's release build uses -O3 by default, which is different from the previous makefile's -O2-by-default. I didn't see a reason to change this, but this means that the default release builds have differences caused by this, so the diff I did above was done by explicitly specifying CMake's flags to use -O2

alexcrichton · 2025-12-02T23:34:25Z

@sbc100 and/or @pchickey would y'all be up for perhaps a call where I run through this to help out with review? I'm happy to help out in making this an easier beast to approach

sbc100

A very impressive feat!

I can't say I reviewed every line but if the tests pass the lgtm

CMakeLists.txt

sbc100 · 2025-12-03T00:06:15Z

CMakeLists.txt

+#
+include(GNUInstallDirs)
+install(DIRECTORY ${SYSROOT}/include/ DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
+install(DIRECTORY ${SYSROOT}/lib/ DESTINATION ${CMAKE_INSTALL_LIBDIR})


Does cmake always make sure it builds all the libs in ${SYSROOT}/lib/ before running this install step? i.e. does it always to a make all before running any install steps?

I believe so yeah, the install target in the generated build system has a dependency on the all target which ensures that the sysroot is filled in

sbc100 · 2025-12-03T00:08:21Z

expected/wasm32-wasip2/predefined-macros.txt

 #define __wasilibc___typedef_time_t_h 
 #define __wasilibc___typedef_uid_t_h 
-#define __wasilibc_use_wasip2 1
+#define __wasilibc_use_wasip2 


Do you know why these expected files change?

This was due to this change, notably replacing an empty file with a CMake-generated *.h.in file (which is configured during the cmake configuration process)

sbc100 · 2025-12-03T00:10:17Z

libc-bottom-half/getpid/CMakeLists.txt

@@ -0,0 +1,3 @@
+add_internal_library_pair(wasi-emulated-getpid getpid.c)
+sysroot_lib(wasi-emulated-getpid-static libwasi-emulated-getpid.a)
+sysroot_lib(wasi-emulated-getpid libwasi-emulated-getpid.so)


Is it worth having all these small CMakeLists.txt? Does cmake dictate that each libray have its own file?

I went back-and-forth on this myself having originally written this as one monolithic CMakeLists.txt and then refactoring to this. My impression was that idiomatic CMake has a CMakeLists.txt roughly per-directory containing the build logic for that directory itself which is what I tried to mirror here.

This folder in particular is a bit extreme since it's just a single C file going into a library, but the libc-bottom-half/signal/CMakeLists.txt file was more substantial for example. Overall I personally felt that the per-directory build felt better than a single monolithic configuration file if only to cut down the size of all the file paths mentioned

alexcrichton mentioned this pull request Nov 21, 2025

[WIP] Add CMake build system #330

Draft

3 tasks

Disable check-symbols by default

3d47081

pchickey requested a review from sbc100 November 24, 2025 19:45

sbc100 reviewed Dec 3, 2025

View reviewed changes

Fix typo

d26d575

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Migrate the `Makefile` to CMake #685

Migrate the `Makefile` to CMake #685

alexcrichton commented Nov 21, 2025 •

edited

Loading

Uh oh!

alexcrichton commented Nov 21, 2025

Uh oh!

alexcrichton commented Dec 2, 2025

Uh oh!

sbc100 left a comment

Uh oh!

Uh oh!

sbc100 Dec 3, 2025

Uh oh!

alexcrichton Dec 3, 2025

Uh oh!

sbc100 Dec 3, 2025

Uh oh!

alexcrichton Dec 3, 2025

Uh oh!

sbc100 Dec 3, 2025

Uh oh!

alexcrichton Dec 3, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Migrate the Makefile to CMake #685

Are you sure you want to change the base?

Migrate the Makefile to CMake #685

Conversation

alexcrichton commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexcrichton commented Nov 21, 2025

Uh oh!

alexcrichton commented Dec 2, 2025

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sbc100 Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

alexcrichton Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

sbc100 Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

alexcrichton Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

sbc100 Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

alexcrichton Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Migrate the `Makefile` to CMake #685

Migrate the `Makefile` to CMake #685

alexcrichton commented Nov 21, 2025 •

edited

Loading