Update all LLVM documentation mentioning runtimes in LLVM_ENABLE_PROJECTS

[ldionne]

Summary

We are moving away from building the runtimes with LLVM_ENABLE_PROJECTS,
however the documentation was largely outdated. This commit updates all
the documentation I could find to use LLVM_ENABLE_RUNTIMES instead of
LLVM_ENABLE_PROJECTS for building runtimes.

Note that in the near future, libcxx, libcxxabi and libunwind will stop
supporting being built with LLVM_ENABLE_PROJECTS altogether. I don't know
what the plans are for other runtimes like libc, openmp and compiler-rt,
so I didn't make any changes to the documentation that would imply
something for those projects.

Once this lands, I will also cherry-pick this on the release/14.x branch
to make sure that LLVM's documentation is up-to-date and reflects what
we intend to support in the future.

[rafauler]

BOLT modifications LGTM, thanks

[• Quuxplusone]

bolt/docs/OptimizingClang.md

229–236

FWIW, I personally prefer to run cmake and ninja from the build directory, i.e.

$ mkdir ${TOPLEV}/llvm-project/llvm/stage2-prof-gen
$ cd ${TOPLEV}/llvm-project/llvm/stage2-prof-gen
$ CPATH=${TOPLEV}/stage1/install/bin
$ cmake -G Ninja \
    -DLLVM_TARGETS_TO_BUILD=X86 \
    ~~~
    -DCMAKE_INSTALL_PREFIX=${TOPLEV}/stage2-prof-gen/install \
    ../llvm-project/llvm
$ ninja install

This is the style that was used in DataFlowSanitizer.rst below, which you explicitly moved away from into -B/-S/-C land (where I find it harder to keep straight all the different extra options that are needed).

Orthogonally, I'm worried that the advice on lines 73–74 of README.md doesn't mention CMAKE_INSTALL_PREFIX. When I'm building libc++ locally as part of my development workflow, I absolutely do not want to blow away my computer's default standard library installation; but what do I want to do? Should I use something like -DCMAKE_INSTALL_PREFIX=$(pwd)/install as depicted here? Can I really not get away with "running it out of the buildroot" the way I'm used to?— I must install it somewhere on my system in order to test it at all?

flang/README.md

36–37

[MaskRay]

Thanks for improving the documentation. I occasionally see folks (and two today!) puzzled by LLVM_ENABLE_RUNTIMES and this patch should help them.

Personally I use the -S -B style (actually -H, but now I see that -S is documented I will switch).
I sometimes twiddle with a cmake file and spawn multiple builds.
Not changing the work directory makes my commands simpler, but I do see @Quuxplusone's point about -DCMAKE_INSTALL_PREFIX=$(pwd)/install.

I rarely use CMAKE_INSTALL_PREFIX. When I need it, I accept the slight inconvenience of duplicating the build directory twice for -B and -DCMAKE_INSTALL_PREFIX.

I have read the updated and they look good to me, but happy if we switch to @Quuxplusone's style.
I passes the link to some folks and hope that fresh eyes with less LLVM_ENABLE_RUNTIMES experience can make suggestions.

[tianshilei1992]

README.md

71

FWIW, OpenMP can be put into either of them. In OpenMP doc (https://openmp.llvm.org/SupportAndFAQ.html#q-how-to-build-an-openmp-gpu-offload-capable-compiler), we recommend to use LLVM_ENABLE_RUNTIMES to build OpenMP if users would like to use offloading features.

[ldionne]

Address review comments.

README.md

71

Thanks for the clarification, I tweaked the documentation a bit.

bolt/docs/OptimizingClang.md

229–236

Re: -C -B -S

I really like using those flags because it makes the command relocatable, i.e. it works regardless of where it is being run. As such, it's way more copy-pasteable too. However, since that's orthogonal to this change, I'll revert to the old style just so we have fewer things to argue about. But in general, for libc++/libc++abi/libunwind instructions, you'll find that I want things documented this way for that reason.

Re: CMAKE_INSTALL_PREFIX

You don't necessarily need to install it in order to test it -- we test libc++ all the time without running the install-cxx target. Furthermore, I would expect that most systems nowadays have some sort of integrity protection that prevents you from doing something bad like that. Apple platforms certainly do -- you simply can't overwrite your libc++.1.dylib anymore and render your system unusable. Still, I'll add a word of caution to CMAKE_INSTALL_PREFIX above even though it's orthogonal to this patch -- it's easy enough to do.

[• Quuxplusone]

bolt/docs/OptimizingClang.md

229–236

FWIW, the CMAKE_INSTALL_PREFIX change is an improvement but only slightly more reassuring than before. ;) Part of my paranoia is that I happen to know that Homebrew stores things in /usr/local/... as well (although probably entirely under /usr/local/Cellar/...?) and I wouldn't want to blow those away either.
Apparently on my Apple system I have /usr/lib/libc++.dylib, /System/DriverKit/usr/lib/libc++.dylib, and /usr/local/Cellar/llvm/12.0.1/lib/libc++.dylib.

we test libc++ all the time without running the install-cxx target

Well, I know I do, but I don't use ENABLE_RUNTIMES yet... and the how-to below does end with the line ninja -C build install-cxx. If there's a supported/expected-to-work way to build and test libc++ that doesn't use ninja install-cxx, it'd be cool to mention it.

Anyway, this is all just me fudding and shouldn't block this PR. :)

llvm/docs/GettingStarted.rst

633–634

The other list is a-z order; this one could be too.

[ldionne]

Address review comments. I'm going to commit this and cherry-pick onto release/14.x

bolt/docs/OptimizingClang.md

229–236

I think your comments are valid, but I think I would defer to @rafauler if they want to change the Bolt documentation in that way.

Well, I know I do, but I don't use ENABLE_RUNTIMES yet...

FWIW, LLVM_ENABLE_RUNTIMES won't change anything with respect to that.

[Arfrever]

llvm/docs/GettingStarted.rst

1225

One space is missing before *, so currently this part of this page is rendered incorrectly. See https://github.com/llvm/llvm-project/blob/main/llvm/docs/GettingStarted.rst (close to the end).

(When you fix it, please also backport fix to branch release/14.x.)

[ldionne]

llvm/docs/GettingStarted.rst

1225

Thanks, good catch.

README.md

* ``cmake -S llvm -B build -G <generator> [options]``
           build files. Most llvm developers use Ninja.
         * ``Unix Makefiles`` --- for generating make-compatible parallel makefiles.
         * ``Visual Studio`` --- for generating Visual Studio projects and
           solutions.
         * ``Xcode`` --- for generating Xcode projects.
 
         Some common options:
 
-        * ``-DLLVM_ENABLE_PROJECTS='...'`` --- semicolon-separated list of the LLVM
-          sub-projects you'd like to additionally build. Can include any of: clang,
-          clang-tools-extra, compiler-rt,cross-project-tests, flang, libc, libclc,
-          libcxx, libcxxabi, libunwind, lld, lldb, mlir, openmp, polly, or pstl.
+        * ``-DLLVM_ENABLE_PROJECTS='...'`` and ``-DLLVM_ENABLE_RUNTIMES='...'`` ---
+          semicolon-separated list of the LLVM sub-projects and runtimes you'd like to
+          additionally build. ``LLVM_ENABLE_PROJECTS`` can include any of: clang,
+          clang-tools-extra, cross-project-tests, flang, libc, libclc, lld, lldb,
+          mlir, openmp, polly, or pstl. ``LLVM_ENABLE_RUNTIMES`` can include any of
+          libcxx, libcxxabi, libunwind, compiler-rt, libc or openmp. Some runtime
+          projects can be specified either in ``LLVM_ENABLE_PROJECTS`` or in
+          ``LLVM_ENABLE_RUNTIMES``.
 
           For example, to build LLVM, Clang, libcxx, and libcxxabi, use
-          ``-DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi"``.
+          ``-DLLVM_ENABLE_PROJECTS="clang" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi"``.
 
         * ``-DCMAKE_INSTALL_PREFIX=directory`` --- Specify for *directory* the full
           path name of where you want the LLVM tools and libraries to be installed
-          (default ``/usr/local``).
+          (default ``/usr/local``). Be careful if you install runtime libraries: if
+          your system uses those provided by LLVM (like libc++ or libc++abi), you
+          must not overwrite your system's copy of those libraries, since that
+          could render your system unusable. In general, using something like
+          ``/usr`` is not advised, but ``/usr/local`` is fine.
 
         * ``-DCMAKE_BUILD_TYPE=type`` --- Valid options for *type* are Debug,
           Release, RelWithDebInfo, and MinSizeRel. Default is Debug.
 
         * ``-DLLVM_ENABLE_ASSERTIONS=On`` --- Compile with assertion checks enabled
           (default is Yes for Debug builds, No for all other build types).
 
       * ``cmake --build build [-- [options] <target>]`` or your build system specified above

bolt/docs/OptimizingClang.md

 Adjust the steps accordingly if you skipped that section. We will also assume that `llvm-bolt` is present in your `$PATH`.
 
 Before we can run BOLT optimizations, we need to collect the profile for Clang, and we will use
 Clang/LLVM sources for that.
 Collecting accurate profile requires running `perf` on a hardware that
 implements taken branch sampling (`-b/-j` flag). For that reason, it may not be possible to
 collect the accurate profile in a virtualized environment, e.g. in the cloud.
 We do support regular sampling profiles, but the performance
-improvements are expected to be more modest. 
+improvements are expected to be more modest.
 
 ```bash
 $ mkdir ${TOPLEV}/stage3
 $ cd ${TOPLEV}/stage3
 $ CPATH=${TOPLEV}/stage2-prof-use-lto/install/bin/
 $ cmake -G Ninja ${TOPLEV}/llvm -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Release \
     -DCMAKE_C_COMPILER=$CPATH/clang -DCMAKE_CXX_COMPILER=$CPATH/clang++ \
     -DLLVM_USE_LINKER=lld -DCMAKE_INSTALL_PREFIX=${TOPLEV}/stage3/install

 `cmake` and `ninja` packages. Note that we disable the build of certain
 compiler-rt components that are known to cause build issues at release/7.x.
 ```bash
 $ mkdir ${TOPLEV}/stage1
 $ cd ${TOPLEV}/stage1
 $ cmake -G Ninja ${TOPLEV}/llvm-project/llvm -DLLVM_TARGETS_TO_BUILD=X86 \
       -DCMAKE_BUILD_TYPE=Release \
       -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_ASM_COMPILER=gcc \
-      -DLLVM_ENABLE_PROJECTS="clang;lld;compiler-rt" \
+      -DLLVM_ENABLE_PROJECTS="clang;lld" \
+      -DLLVM_ENABLE_RUNTIMES="compiler-rt" \
       -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF \
       -DCOMPILER_RT_BUILD_LIBFUZZER=OFF \
       -DCMAKE_INSTALL_PREFIX=${TOPLEV}/stage1/install
 $ ninja install
 ```
 
 ### Building Stage 2 Compiler With Instrumentation
 
 Using the freshly-baked stage 1 Clang compiler, we are going to build Clang with
 profile generation capabilities:
 ```bash
 $ mkdir ${TOPLEV}/stage2-prof-gen
 $ cd ${TOPLEV}/stage2-prof-gen
 $ CPATH=${TOPLEV}/stage1/install/bin/
 $ cmake -G Ninja ${TOPLEV}/llvm-project/llvm -DLLVM_TARGETS_TO_BUILD=X86 \
     -DCMAKE_BUILD_TYPE=Release \
     -DCMAKE_C_COMPILER=$CPATH/clang -DCMAKE_CXX_COMPILER=$CPATH/clang++ \
     -DLLVM_ENABLE_PROJECTS="clang;lld" \
     -DLLVM_USE_LINKER=lld -DLLVM_BUILD_INSTRUMENTED=ON \
     -DCMAKE_INSTALL_PREFIX=${TOPLEV}/stage2-prof-gen/install
 $ ninja install
 ```
 
 ### Generating Profile for PGO
 
 While there are many ways to obtain the profile data, we are going to use the
 source code already at our disposal, i.e. we are going to collect the profile
 while building Clang itself:
 ```bash

clang/docs/DataFlowSanitizer.rst

 functions to be listed as ``uninstrumented`` in the `ABI list`_.
 
 If you'd like to have instrumented libc++ functions, then you need to build it
 with DFSan instrumentation from source. Here is an example of how to build
 libc++ and the libc++ ABI with data flow sanitizer instrumentation.
 
 .. code-block:: console
 
+  mkdir libcxx-build
   cd libcxx-build
 
   # An example using ninja
-  cmake -GNinja path/to/llvm-project/llvm \
+  cmake -GNinja -S <monorepo-root>/runtimes \
     -DCMAKE_C_COMPILER=clang \
     -DCMAKE_CXX_COMPILER=clang++ \
     -DLLVM_USE_SANITIZER="DataFlow" \
-    -DLLVM_ENABLE_LIBCXX=ON \
-    -DLLVM_ENABLE_PROJECTS="libcxx;libcxxabi"
+    -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi"
 
   ninja cxx cxxabi
 
 Note: Ensure you are building with a sufficiently new version of Clang.
 
 Usage
 =====
 

clang/docs/Toolchain.rst

 (`Level I <https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#base-abi>`_).
 It is a dependency of the C++ ABI library, and sometimes is a dependency
 of other runtimes.
 
 libunwind (LLVM)
 ^^^^^^^^^^^^^^^^
 
 LLVM's unwinder library is part of the llvm-project git repository. To
-build it, pass ``-DLLVM_ENABLE_PROJECTS=libunwind`` to the cmake invocation.
+build it, pass ``-DLLVM_ENABLE_RUNTIMES=libunwind`` to the cmake invocation.
 
 If using libc++abi, you may need to configure it to use libunwind
 rather than libgcc_s by passing ``-DLIBCXXABI_USE_LLVM_UNWINDER=YES``
 to ``cmake``. If libc++abi is configured to use some version of
 libunwind, that library will be implicitly linked into binaries that
 link to libc++abi.
 
 libgcc_s (GNU)

compiler-rt/www/index.html

<div id="content">
 
   <!--=====================================================================-->
   <h2>Get it and get involved!</h2>
   <!--=====================================================================-->
 
   <p>Generally, you need to build LLVM/Clang in order to build compiler-rt. You
     can build it either together with llvm and clang, or separately.
 
-  <p>To build it together, simply add compiler-rt to the -DLLVM_ENABLE_PROJECTS= option to
+  <p>To build it together, simply add compiler-rt to the -DLLVM_ENABLE_RUNTIMES= option to
     cmake.
 
   <p>To build it separately, first
   <a href="https://llvm.org/docs/CMake.html#quick-start">build LLVM</a>
   separately to get llvm-config binary, and then run:
 
   <ul>
   <li>cd llvm-project</li>

flang/README.md

 To understand how a flang program communicates with libraries at runtime,
 see the discussion of [runtime descriptors](docs/RuntimeDescriptor.md).
 
 If you're interested in contributing to the compiler,
 read the [style guide](docs/C++style.md)
 and
 also review [how flang uses modern C++ features](docs/C++17.md).
 
-If you are interested in writing new documentation, follow 
-[markdown style guide from LLVM](https://github.com/llvm/llvm-project/blob/main/llvm/docs/MarkdownQuickstartTemplate.md).
+If you are interested in writing new documentation, follow
+[LLVM's Markdown style guide](https://github.com/llvm/llvm-project/blob/main/llvm/docs/MarkdownQuickstartTemplate.md).
 
 ## Building flang
 There are two ways to build flang. The first method is to build it at the same
 time that you build all of the projects on which it depends. This is called
 building in tree. The second method is to first do an in tree build to create
 all of the projects on which flang depends, and then only build the flang code
 itself. This is called building standalone. Building standalone has the
 advantage of being smaller and faster. Once you create the base build and base
 install areas, you can create multiple standalone builds using them.
 
 Note that instructions for building LLVM can be found at
 https://llvm.org/docs/GettingStarted.html.
 
 ### Building flang in tree
 Building flang in tree means building flang along with all of the projects on
 which it depends.  These projects include mlir, clang, flang, and compiler-rt.
 Note that compiler-rt is only needed to access libraries that support 16 bit
 floating point numbers.  It's not needed to run the automated tests.
 
 Here's a complete set of commands to clone all of the necessary source and do
-the build.  
+the build.
 
 First clone the source:
 ```bash
 git clone https://github.com/llvm/llvm-project.git my-project
 ```
 Once the clone is complete, execute the following commands:
 ```bash
 cd my-project
 
 rm -rf build
 mkdir -p build
 
 cd build
 
 cmake \
   -G Ninja \
   ../llvm \
   -DCMAKE_BUILD_TYPE=Release \
   -DFLANG_ENABLE_WERROR=On \
   -DLLVM_ENABLE_ASSERTIONS=ON \
   -DLLVM_TARGETS_TO_BUILD=host \
   -DCMAKE_INSTALL_PREFIX=$INSTALLDIR
   -DLLVM_LIT_ARGS=-v \
-  -DLLVM_ENABLE_PROJECTS="clang;mlir;flang;compiler-rt"
+  -DLLVM_ENABLE_PROJECTS="clang;mlir;flang" \
+  -DLLVM_ENABLE_RUNTIMES="compiler-rt"
 
 ninja
 ```
 
 To run the flang tests on this build, execute the command in the "build"
 directory:
 ```bash
 ninja check-flang

libcxx/docs/BuildingLibcxx.rst

 
 Note that the first two entries happen to be what we are looking for. This
 may not be correct on all platforms.
 
 We can now run CMake:
 
 .. code-block:: bash
 
-  $ cmake -G Ninja -S llvm -B build           \
-    -DLLVM_ENABLE_PROJECTS="libcxx"           \
+  $ cmake -G Ninja -S runtimes -B build       \
+    -DLLVM_ENABLE_RUNTIMES="libcxx"           \
     -DLIBCXX_CXX_ABI=libstdc++                \
     -DLIBCXX_CXX_ABI_INCLUDE_PATHS="/usr/include/c++/4.7/;/usr/include/c++/4.7/x86_64-linux-gnu/"
   $ ninja -C build install-cxx
 
 
 You can also substitute ``-DLIBCXX_CXX_ABI=libsupc++``
 above, which will cause the library to be linked to libsupc++ instead
 of libstdc++, but this is only recommended if you know that you will
 never need to link against libstdc++ in the same executable as libc++.
 GCC ships libsupc++ separately but only as a static library.  If a
 program also needs to link against libstdc++, it will provide its
 own copy of libsupc++ and this can lead to subtle problems.
 
 Using libcxxrt on Linux
 ------------------------
 
 You will need to keep the source tree of `libcxxrt`_ available
 on your build machine and your copy of the libcxxrt shared library must
 be placed where your linker will find it.
 
 We can now run CMake like:
 
 .. code-block:: bash
 
-  $ cmake -G Ninja -S llvm -B build                                   \
-          -DLLVM_ENABLE_PROJECTS="libcxx"                             \
+  $ cmake -G Ninja -S runtimes -B build                               \
+          -DLLVM_ENABLE_RUNTIMES="libcxx"                             \
           -DLIBCXX_CXX_ABI=libcxxrt                                   \
           -DLIBCXX_CXX_ABI_INCLUDE_PATHS=path/to/libcxxrt-sources/src
   $ ninja -C build install-cxx
 
 Unfortunately you can't simply run clang with "-stdlib=libc++" at this point, as
 clang is set up to link for libc++ linked to libsupc++.  To get around this
 you'll have to set up your linker yourself (or patch clang).  For example,
 

libunwind/docs/BuildingLibunwind.rst

#. Configure and build libunwind:
 
    CMake is the only supported configuration system.
 
    Clang is the preferred compiler when building and using libunwind.
 
    * ``cd where you want to build llvm``
    * ``mkdir build``
    * ``cd build``
-   * ``cmake -G <generator> -DLLVM_ENABLE_PROJECTS=libunwind [options] <path to llvm sources>``
+   * ``cmake -G <generator> -DLLVM_ENABLE_RUNTIMES=libunwind [options] <llvm-monorepo>/runtimes``
 
    For more information about configuring libunwind see :ref:`CMake Options`.
 
    * ``make unwind`` --- will build libunwind.
    * ``make check-unwind`` --- will run the test suite.
 
    Shared and static libraries for libunwind should now be present in llvm/build/lib.
 

llvm/docs/BuildingADistribution.rst

.. warning::
   option. (:ref:`See the warning above for more explanation <shared_libs>`.).
 
 Relevant CMake Options
 ======================
 
 This section provides documentation of the CMake options that are intended to
 help construct distributions. This is not an exhaustive list, and many
 additional options are documented in the :doc:`CMake` page. Some key options
-that are already documented include: *LLVM_TARGETS_TO_BUILD*,
-*LLVM_ENABLE_PROJECTS*, *LLVM_BUILD_LLVM_DYLIB*, and *LLVM_LINK_LLVM_DYLIB*.
+that are already documented include: *LLVM_TARGETS_TO_BUILD*, *LLVM_ENABLE_PROJECTS*,
+*LLVM_ENABLE_RUNTIMES*, *LLVM_BUILD_LLVM_DYLIB*, and *LLVM_LINK_LLVM_DYLIB*.
 
 **LLVM_ENABLE_RUNTIMES**:STRING
   When building a distribution that includes LLVM runtime projects (i.e. libcxx,
   compiler-rt, libcxxabi, libunwind...), it is important to build those projects
   with the just-built compiler.
 
 **LLVM_DISTRIBUTION_COMPONENTS**:STRING
   This variable can be set to a semi-colon separated list of LLVM build system

llvm/docs/CMake.rst

 The default configuration may not match your requirements. Here are
 LLVM variables that are frequently used to control that. The full
 description is in `LLVM-related variables`_ below.
 
 **LLVM_ENABLE_PROJECTS**:STRING
   Control which projects are enabled. For example you may want to work on clang
   or lldb by specifying ``-DLLVM_ENABLE_PROJECTS="clang;lldb"``.
 
+**LLVM_ENABLE_RUNTIMES**:STRING
+  Control which runtimes are enabled. For example you may want to work on
+  libc++ or libc++abi by specifying ``-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi"``.
+
 **LLVM_LIBDIR_SUFFIX**:STRING
   Extra suffix to append to the directory where libraries are to be
   installed. On a 64-bit architecture, one could use ``-DLLVM_LIBDIR_SUFFIX=64``
   to install libraries to ``/usr/lib64``.
 
 **LLVM_PARALLEL_{COMPILE,LINK}_JOBS**:STRING
   Building the llvm toolchain can use a lot of resources, particularly
   linking. These options, when you use the Ninja generator, allow you
**LLVM_ENABLE_PEDANTIC**:BOOL
   possible. Defaults to ON.
 
 **LLVM_ENABLE_PIC**:BOOL
   Add the ``-fPIC`` flag to the compiler command-line, if the compiler supports
   this flag. Some systems, like Windows, do not need this flag. Defaults to ON.
 
 **LLVM_ENABLE_PROJECTS**:STRING
   Semicolon-separated list of projects to build, or *all* for building all
-  (clang, lldb, compiler-rt, lld, polly, etc) projects. This flag assumes
-  that projects are checked out side-by-side and not nested, i.e. clang
-  needs to be in parallel of llvm instead of nested in `llvm/tools`.
-  This feature allows to have one build for only LLVM and another for clang+llvm
-  using the same source checkout.
+  (clang, lldb, lld, polly, etc) projects. This flag assumes that projects
+  are checked out side-by-side and not nested, i.e. clang needs to be in
+  parallel of llvm instead of nested in `llvm/tools`. This feature allows
+  to have one build for only LLVM and another for clang+llvm using the same
+  source checkout.
   The full list is:
-  ``clang;clang-tools-extra;compiler-rt;cross-project-tests;libc;libclc;lld;lldb;openmp;polly;pstl``
+  ``clang;clang-tools-extra;cross-project-tests;libc;libclc;lld;lldb;openmp;polly;pstl``
 
 **LLVM_ENABLE_RUNTIMES**:STRING
-  Build libc++, libc++abi or other projects using that a just-built compiler.
-  This is the correct way to build libc++ when putting together a toolchain.
+  Build libc++, libc++abi, libunwind or compiler-rt using the just-built compiler.
+  This is the correct way to build runtimes when putting together a toolchain.
   It will build the builtins separately from the other runtimes to preserve
   correct dependency ordering. If you want to build the runtimes using a system
   compiler, see the `libc++ documentation <https://libcxx.llvm.org/BuildingLibcxx.html>`_.
   Note: the list should not have duplicates with `LLVM_ENABLE_PROJECTS`.
   The full list is:
   ``compiler-rt;libc;libcxx;libcxxabi;libunwind;openmp``
   To enable all of them, use:
   ``LLVM_ENABLE_RUNTIMES=all``

llvm/docs/GettingStarted.rst

 | LLVM_ENABLE_DOXYGEN     | Build doxygen-based documentation from the source  |
 |                         | code This is disabled by default because it is     |
 |                         | slow and generates a lot of output.                |
 +-------------------------+----------------------------------------------------+
 | LLVM_ENABLE_PROJECTS    | A semicolon-delimited list selecting which of the  |
 |                         | other LLVM subprojects to additionally build. (Only|
 |                         | effective when using a side-by-side project layout |
 |                         | e.g. via git). The default list is empty. Can      |
-|                         | include: clang, clang-tools-extra, compiler-rt,    |
-|                         | cross-project-tests, flang, libc, libclc, libcxx,  |
-|                         | libcxxabi, libunwind, lld, lldb, mlir, openmp,     |
-|                         | polly, or pstl.                                    |
+|                         | include: clang, clang-tools-extra,                 |
+|                         | cross-project-tests, flang, libc, libclc, lld,     |
+|                         | lldb, mlir, openmp, polly, or pstl.                |
++-------------------------+----------------------------------------------------+
+| LLVM_ENABLE_RUNTIMES    | A semicolon-delimited list selecting which of the  |
+|                         | runtimes to build. (Only effective when using the  |
+|                         | full monorepo layout). The default list is empty.  |
+|                         | Can include: compiler-rt, libc, libcxx, libcxxabi, |
+|                         | libunwind, or openmp.                              |
 +-------------------------+----------------------------------------------------+
 | LLVM_ENABLE_SPHINX      | Build sphinx-based documentation from the source   |
 |                         | code. This is disabled by default because it is    |
 |                         | slow and generates a lot of output. Sphinx version |
 |                         | 1.5 or later recommended.                          |
 +-------------------------+----------------------------------------------------+
 | LLVM_BUILD_LLVM_DYLIB   | Generate libLLVM.so. This library contains a       |
 |                         | default set of LLVM components that can be         |
* -DLLVM_OPTIMIZED_TABLEGEN
    will significantly improve your build time. This is only useful if you are
    using the Debug build type.
 
  * -DLLVM_ENABLE_PROJECTS
    Set this equal to the projects you wish to compile (e.g. clang, lld, etc.) If
    compiling more than one project, separate the items with a semicolon. Should
    you run into issues with the semicolon, try surrounding it with single quotes.
 
+* -DLLVM_ENABLE_RUNTIMES
+   Set this equal to the runtimes you wish to compile (e.g. libcxx, libcxxabi, etc.)
+   If compiling more than one runtime, separate the items with a semicolon. Should
+   you run into issues with the semicolon, try surrounding it with single quotes.
+
  * -DCLANG_ENABLE_STATIC_ANALYZER
    Set this option to OFF if you do not require the clang static analyzer. This
    should improve your build time slightly.
 
  * -DLLVM_USE_SPLIT_DWARF
    Consider setting this to ON if you require a debug build, as this will ease
    memory pressure on the linker. This will make linking much faster, as the
    binaries will not contain any of the debug information; however, this will