Rewrite the build system with CMake #429
Conversation
|
A few other points of note:
|
There was a problem hiding this comment.
I'm not the greatest fan of cmake I have to say. I tend to find shell scripts that are transliterated into cmake even harder to deal with than the originals.
However, you seem to have done all the due diligence here and cmake sounds like it is the best worst option. I wish we had some other/nicer option here but I'm not sure we do.
Thanks for all the efforts here BTW, I know this kind of work can be real pain.
| target_compile_options(${target_name} PRIVATE -D_WASI_EMULATED_MMAN) | ||
| target_link_options(${target_name} PRIVATE -lwasi-emulated-mman) | ||
| elseif(test MATCHES "(sigabrt|signals).c$") | ||
| target_compile_options(${target_name} PRIVATE -D_WASI_EMULATED_SIGNAL) |
There was a problem hiding this comment.
Can we not keep the existing .options file thing that reads the options from a file alongside the test?
There was a problem hiding this comment.
I tried yeah but I couldn't figure out a way to easily read options from a file at test-compile-time while also rebuilding the test if the file appeared, disappeared, or got modified. This was the least-bad alternative that I could come up with
| @@ -1,7 +1,7 @@ | |||
| # Cmake toolchain description file for the Makefile | |||
|
|
|||
| # This is arbitrary, AFAIK, for now. | |||
| cmake_minimum_required(VERSION 3.4.0) | |||
There was a problem hiding this comment.
Is this file (along with the Platform file) now being used as part of the build? Or maybe its being used to build the examples?
There was a problem hiding this comment.
Correct yeah, this was done since CMake was spewing a warning-per-compile (aka lots) that CMake itself is dropping support for 3.4.0 so I bumped this to 3.5.0 to stop CMake from warning.
There was a problem hiding this comment.
FYI, once #430 is merged, we'll want to make the same change to wasi-sdk-p2.cmake
To be clear I completely agree with you. I'm no fan of cmake myself, but AFAIK it's the only build-system-style solution that works across Windows/macOS/Linux. Shell scripts to me chiefly break down on Windows. I also think that cmake has a lot to offer once you get past the "wow that sure is cmake" since it has functions/if-else/loops/etc in addition to being able to define a build system which ends up being pretty flexibly. I definitely agree though that the syntax leaves a bit to be desired. |
There was a problem hiding this comment.
Like @sbc100, I have been a bit skeptical about switching to CMake in the past. But more recently I am more convinced: it takes on the cross-platform portability burden and it's heavily used out there in the ecosystem (not to mention in LLVM itself). Thanks @alexcrichton for working on this--it's the initial push that was needed to do the switch. I'll let you and @sbc100 figure out any final details but I'm a +1 on this. (I saw up above that some CI settings need to change? Let me know what they are and I'll tweak those.)
|
It would be very nice to make |
|
I'm not necessarily in any rush to merge this, but I also want to pose a question as to what the next steps for this would be. For example do folks feel this should stay open for awhile to gather more feedback? Or is there anyone in particular I should reach out to and consult on this? @TerrorJack happy to add other build options, should be pretty easy to do so. That being said I'd like to delve further into the motivations because I think it's best to have a consistent sysroot where possible (e.g. omitting |
|
@alexcrichton Nope, just assuming |
|
Ok I'd still regardless like to discuss further (but probably not here since it's orthogonal). For example I'd like to understand why |
|
Does this build system allow not to build clang/llvm before building the sdk? |
|
Yes, it's possible to build just the sysroot since the build is split in two halves. One caveat is that due to how compiler-rt library lookup works the build system tries to install compiler-rt in the in-use toolchain's sysroot, so that will probably need tweaks over time. |
|
I figured I'll solicit once more for thoughts on this, and pending that I'll try to work with @abrown later this week with respect to repo settings to merge. |
This commit is an attempt to provide a concrete path forward on WebAssembly#425. I personally think it's pretty important to get the ability to have more architectures here but at the same time I also think it's important to to take this as an opportunity to refactor and improve the build system of this repository. To that end this represents my attempt to improve the status quo. This removes the old `Makefile` and replaces it with a CMake-based system to build all these projects. Overall this is intended to be a "no functional change" intended sort of refactoring. Changing build systems inevitably causes issues, however, so this change additionally has a very high likelihood of needing follow-up fixes. At a high enough level this commit introduces two major changes to how this repository is built: 1. The `make`-based system (the root `Makefile`) is replaced with CMake. This additionally updates tests to use CMake. 2. A single "build" is split into either building a toolchain or building a sysroot. This enables builds to only build one or the other as necessary. The first change, using CMake, is due to the fact that using `make` on Windows basically is not pleasant coupled with the fact that more advanced logic, such as changing flags, compilers, etc, is much easier with a CMake-based system. The second change is intended to cover the use case of WebAssembly#425 in addition to refactoring the current build. Throughout this change I have intentionally not tried to keep a 1:1 correspondance with behaviors in the old `Makefile` because much of this PR is intended to address shortcomings in the old build system. A list of changes, improvements, etc, made here are: * CMake provides a much nicer portability story to Windows than `make`. This is moving towards the direction of not needing `bash`, for example, to build an SDK. Currently `wasi-libc` still requires this, but that's now the only "hard" dependency. * The set of targets built can now be configured for smaller builds and/or debugging just a single target. All WASI targets are still built by default but it's much easier to add/remove them. * Different targets are now able to be built in parallel as opposed to the unconditional serial-nature of the `Makefile`. * Use of `ninja` is no longer required and separate build systems can be used if desired. * The sysroot and the toolchain can now be built with different CMake build profiles. For example the `Makefile` hardcoded `MinSizeRel` and `RelWithDebInfo` and this can now be much more easily customized by the SDK builder. * Tarballs are now more consistently produced and named. For a tarball of the name `foo.tar.gz` it's guaranteed that there's a single folder `foo` created when unpacking the tarball. * The macOS binaries are no longer hybrid x64/arm64 binaries which greatly inflates the size of the SDK. There's now a separate build for each architecture. * CI now produces arm64-linux binaries. The sysroot is not built on the arm64-linux builder and the sysroot from the x86_64-linux builder is used instead. * Tests are almost ready to execute on Windows, there's just a few minor issues related to exit statuses and probably line endings which need to be worked out. Will require someone with a Windows checkout, however. * Tests are now integrated into CMake. This means that the wasm binaries are able to be built in parallel and the tests are additionally executed in parallel with `ctest`. It is possible to build/run a single test. Tests no longer place all of their output in the source tree. * Out-of-tree builds are now possible and the build/installation directories can both be customized. * CI configuration of Windows/macOS/Linux is much more uniform by having everything in one build matrix instead of separate matrices. * Linux builds are exclusively done in docker containers in CI now. CI no longer produces two Linux builds only for one to be discarded when artifacts are published. * Windows 32-bit builds are no longer produced in CI since it's expected that everyone actually wants the 64-bit ones instead. * Use of `ccache` is now automatically enabled if it's detected on the system. * Many preexisting shell scripts are now translated to CMake one way or another. * There's no longer a separate build script for how to build wasi-sdk in docker and outside of docker which needs to be kept in sync, everything funnels through the same script. * The `docker/Dockerfile` build of wasi-sdk now uses the actual toolchain built from CI and additionally doesn't duplicate various CMake-based configuration files. Overall one thing I want to additionally point out is that I'm not CMake expert. I suspect there's lots of little stylistic and such improvements that can be made.
|
@abrown has now removed the gates on specific status checks which enables this PR to merge. I'll wait for green CI and then merge it and then we'll re-enable the gates on the new status checks that this PR introduces. |
Updating for the rewrite in WebAssembly#429
Updating for the rewrite in #429
This commit is an attempt to provide a concrete path forward on #425. I personally think it's pretty important to get the ability to have more architectures here but at the same time I also think it's important to to take this as an opportunity to refactor and improve the build system of this repository. To that end this represents my attempt to improve the status quo.
This removes the old
Makefileand replaces it with a CMake-based system to build all these projects. Overall this is intended to be a "no functional change" intended sort of refactoring. Changing build systems inevitably causes issues, however, so this change additionally has a very high likelihood of needing follow-up fixes. At a high enough level this commit introduces two major changes to how this repository is built:make-based system (the rootMakefile) is replaced with CMake. This additionally updates tests to use CMake.The first change, using CMake, is due to the fact that using
makeon Windows basically is not pleasant coupled with the fact that more advanced logic, such as changing flags, compilers, etc, is much easier with a CMake-based system. The second change is intended to cover the use case of #425 in addition to refactoring the current build.Throughout this change I have intentionally not tried to keep a 1:1 correspondance with behaviors in the old
Makefilebecause much of this PR is intended to address shortcomings in the old build system. A list of changes, improvements, etc, made here are:CMake provides a much nicer portability story to Windows than
make. This is moving towards the direction of not needingbash, for example, to build an SDK. Currentlywasi-libcstill requires this, but that's now the only "hard" dependency.The set of targets built can now be configured for smaller builds and/or debugging just a single target. All WASI targets are still built by default but it's much easier to add/remove them.
Different targets are now able to be built in parallel as opposed to the unconditional serial-nature of the
Makefile.Use of
ninjais no longer required and separate build systems can be used if desired.The sysroot and the toolchain can now be built with different CMake build profiles. For example the
MakefilehardcodedMinSizeRelandRelWithDebInfoand this can now be much more easily customized by the SDK builder.Tarballs are now more consistently produced and named. For a tarball of the name
foo.tar.gzit's guaranteed that there's a single folderfoocreated when unpacking the tarball.The macOS binaries are no longer hybrid x64/arm64 binaries which greatly inflates the size of the SDK. There's now a separate build for each architecture.
CI now produces arm64-linux binaries. The sysroot is not built on the arm64-linux builder and the sysroot from the x86_64-linux builder is used instead.
Tests are almost ready to execute on Windows, there's just a few minor issues related to exit statuses and probably line endings which need to be worked out. Will require someone with a Windows checkout, however.
Tests are now integrated into CMake. This means that the wasm binaries are able to be built in parallel and the tests are additionally executed in parallel with
ctest. It is possible to build/run a single test. Tests no longer place all of their output in the source tree.Out-of-tree builds are now possible and the build/installation directories can both be customized.
CI configuration of Windows/macOS/Linux is much more uniform by having everything in one build matrix instead of separate matrices.
Linux builds are exclusively done in docker containers in CI now. CI no longer produces two Linux builds only for one to be discarded when artifacts are published.
Windows 32-bit builds are no longer produced in CI since it's expected that everyone actually wants the 64-bit ones instead.
Use of
ccacheis now automatically enabled if it's detected on the system.Many preexisting shell scripts are now translated to CMake one way or another.
There's no longer a separate build script for how to build wasi-sdk in docker and outside of docker which needs to be kept in sync, everything funnels through the same script.
The
docker/Dockerfilebuild of wasi-sdk now uses the actual toolchain built from CI and additionally doesn't duplicate various CMake-based configuration files.Overall one thing I want to additionally point out is that I'm not CMake expert. I suspect there's lots of little stylistic and such improvements that can be made.