From fd1f52da5dc120c108340ad857e7193843fd4113 Mon Sep 17 00:00:00 2001 From: wyattscarpenter Date: Fri, 29 Mar 2024 22:43:14 -0400 Subject: [PATCH] enact: "For consistency, I would also update the following to make it more clear that you should use cmake" Notably, I don't actually know how COMPONENTS works, because I don't know cmake, so I guessed. --- src/build-instructions.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/build-instructions.md b/src/build-instructions.md index fddddc6..880545c 100644 --- a/src/build-instructions.md +++ b/src/build-instructions.md @@ -180,6 +180,7 @@ Another way to speed up the build is to run `make` with multiple jobs. For this, ### "Unified" JavaScriptCore Builds If you still want to build JavaScriptCore and have a bit of RAM to spare, JavaScriptCore also supports a build mode known as ["unified builds"](https://blogs.gnome.org/mcatanzaro/2018/02/17/on-compiling-webkit-now-twice-as-fast/). This build mode can cut JSC build times in half, at the expense of causing slightly higher RAM usage. This build mode can be enabled in Darling by adding `-DJSC_UNIFIED_BUILD=ON` when configuring the build. +That is, run `cmake -DJSC_UNIFIED_BUILD=ON ..` instead of `cmake ..`. ### Ninja build system @@ -194,11 +195,11 @@ If you are using Ninja, the library "libcsu" might fail to link. The solution is ### Debug Builds By default, CMake setups up a non-debug, non-release build. -If you run LLDB and encounter messages indicating a lack of debug symbols, make sure you are doing a debug build. To do this, use `-DCMAKE_BUILD_TYPE=Debug`. +If you run LLDB and encounter messages indicating a lack of debug symbols, make sure you are doing a debug build. To do this, use `-DCMAKE_BUILD_TYPE=Debug` with `cmake`. ### Unit tests -Darling has a limited number of unit tests. These are not currently built by default, but this can be enabled with '-DENABLE_TESTS=1'. +Darling has a limited number of unit tests. These are not currently built by default, but this can be enabled with '-DENABLE_TESTS=1' (given as a flag to `cmake`). These tests are then installed to /usr/libexec within your Darling container. ### Additional, Non-standard Binaries @@ -222,7 +223,7 @@ Normally, you don't need to worry about setting these variables. With that being ### Building Only Certain Components -By default, almost all of Darling is built, similar to what would be a full macOS installation. However, you can also choose to only build certain components of Darling with the `COMPONENTS` configuration option in CMake. This is a comma-separated list of components to build. By default, `COMPONENTS` is set to `stock` (which includes various other components). The following components are currently recognized: +By default, almost all of Darling is built, similar to what would be a full macOS installation. However, you can also choose to only build certain components of Darling with the `COMPONENTS` configuration option in CMake. This is a comma-separated list of components to build. So, for example, you might specify `-DCOMPONENTS=cli,python` as a flag to `cmake`. By default, `COMPONENTS` is set to `stock` (which includes various other components). The following components are currently recognized: * Basic components * `core` - Builds darlingserver, mldr, launchd, and libSystem (in addition to a couple of host-side executables). This is the minimal set of targets necessary to run an executable under Darling. Note that most executables depend on various other programs and system services which are not provided by this component; this will only support extremely bare-bones executables (e.g. a "Hello world" executable).