[runtimes] Remove support for standalone builds

[ldionne]

Summary

Standalone build have been deprecated for some time now, so this
commit removes support for those builds entirely from libc++, libc++abi
and libunwind.

This, along with the removal of other legacy ways to build, will allow
for major build system simplifications.

[ldionne]

Heads up libc++ vendors, if you still depend on this, you should move to the supported ways of building.

Also @thakis I think you were using this at some point unless I'm mistaken (you might want to add yourself to libc++ vendors to be automatically notified about these kinds of things).

[• Quuxplusone]

libcxxabi/www/index.html

76

This sentence is missing the "why". Is the intent something like "If you'd like to get involved with the project, and/or learn how to build libc++ from source, please see the libc++ documentation"? And if so, are there specific "getting started" and/or "getting involved" sections of the libc++ documentation to which you should link, specifically?

[Mordante]

libcxx/docs/ReleaseNotes.rst

56

Can you make the link a .rst link?

[ldionne]

Address review comments

libcxxabi/www/index.html

76

Right -- basically this documentation as a whole is out of date. I'll be more precise.

[dim]

LGTM (@emaste I've never used the standalone build, always as part of the 'full monty' all llvm components)

[ldionne]

I will land this tomorrow morning (EST) and monitor potential failures throughout the day. If you get here through a failure caused by this commit, please ping @ldionne on libc++'s Discord channel.

[ldionne]

@simoll You are marked as responsible for the clang-ve-ninja built bot that broke because of this change here: https://lab.llvm.org/buildbot/#/builders/91/builds/3480.

Are you able to move that bot to the normal runtimes build? Right now the bot is doing:

cd "/scratch/buildbot/bothome/clang-ve-ninja/build/build_libunwind_ve" && cmake /scratch/buildbot/bothome/clang-ve-ninja/build/../llvm-project/libunwind -G Ninja \
    -DLIBUNWIND_TARGET_TRIPLE=""ve-linux"" \
    -DCMAKE_C_COMPILER="""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/bin/clang" \
    -DCMAKE_CXX_COMPILER="""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/bin/clang++" \
    -DCMAKE_AR=""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/bin/llvm-ar \
    -DCMAKE_RANLIB=""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/bin/llvm-ranlib \
    -DCMAKE_C_COMPILER_TARGET=""ve-linux"" \
    -DCMAKE_CXX_COMPILER_TARGET=""ve-linux"" \
    -DCMAKE_BUILD_TYPE="Release" \
    -DCMAKE_INSTALL_PREFIX=""""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/lib/clang/15.0.0"" \
    -DLIBUNWIND_LIBDIR_SUFFIX="/linux/ve" \
    -DCMAKE_CXX_FLAGS="-nostdlib" \
    -DCMAKE_CXX_FLAGS_RELEASE="-O2" \
    -DCMAKE_C_FLAGS="-nostdlib" \
    -DCMAKE_C_FLAGS_RELEASE="-O2" \
    -DLIBUNWIND_LIBCXX_PATH=/scratch/buildbot/bothome/clang-ve-ninja/build/../llvm-project/libcxx \
    -DLLVM_PATH=/scratch/buildbot/bothome/clang-ve-ninja/build/../llvm-project/llvm

Instead, you want to be doing something like this:

cmake -S llvm-project/runtimes -B <BUILD_DIR> -G Ninja \
    -DLIBUNWIND_TARGET_TRIPLE=""ve-linux"" \
    -DCMAKE_C_COMPILER="<whatever>" \
    -DCMAKE_CXX_COMPILER="<whatever>" \
    -DCMAKE_AR="<whatever>" \
    -DCMAKE_RANLIB=""<whatever>" \
    -DCMAKE_C_COMPILER_TARGET="ve-linux" \
    -DCMAKE_CXX_COMPILER_TARGET="ve-linux" \
    -DCMAKE_BUILD_TYPE="Release" \
    -DCMAKE_INSTALL_PREFIX="<whatever>" \
    -DLIBUNWIND_LIBDIR_SUFFIX="/linux/ve" \
    -DCMAKE_CXX_FLAGS="-nostdlib" \
    -DCMAKE_CXX_FLAGS_RELEASE="-O2" \
    -DCMAKE_C_FLAGS="-nostdlib" \
    -DCMAKE_C_FLAGS_RELEASE="-O2" \
    -DLLVM_ENABLE_RUNTIMES="libunwind"

So basically, use <monorepo>/runtimes as the root of the CMake tree, drop LIBUNWIND_LIBCXX_PATH and LLVM_PATH, and add -DLLVM_ENABLE_RUNTIMES="libunwind".

[mstorsjo]

FWIW, I think we should add a cmake warning in the 14.x release if building with the old standalone setup, telling the user that the configuration is deprecated, so users not reading the release notes get a better chance of noticing.

[ldionne]

In D119255#3307852, @mstorsjo wrote:

FWIW, I think we should add a cmake warning in the 14.x release if building with the old standalone setup, telling the user that the configuration is deprecated, so users not reading the release notes get a better chance of noticing.

That's a good point, see D119341.

[ldionne]

No more issues so far -- the buildbot issues should have been shaken out by now, so it seems like the clang-ve-ninja failure might be the only one.

I'll stop actively monitoring this now. If you get here and want support, please reach out on the libc++ Discord channel -- you can also reply here but it's possible that I won't see it amid the flood of Phabricator emails.

[simoll]

In D119255#3307824, @ldionne wrote:

@simoll You are marked as responsible for the clang-ve-ninja built bot that broke because of this change here: https://lab.llvm.org/buildbot/#/builders/91/builds/3480.

Are you able to move that bot to the normal runtimes build? Right now the bot is doing:

cd "/scratch/buildbot/bothome/clang-ve-ninja/build/build_libunwind_ve" && cmake /scratch/buildbot/bothome/clang-ve-ninja/build/../llvm-project/libunwind -G Ninja \
    -DLIBUNWIND_TARGET_TRIPLE=""ve-linux"" \
    -DCMAKE_C_COMPILER="""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/bin/clang" \
    -DCMAKE_CXX_COMPILER="""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/bin/clang++" \
    -DCMAKE_AR=""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/bin/llvm-ar \
    -DCMAKE_RANLIB=""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/bin/llvm-ranlib \
    -DCMAKE_C_COMPILER_TARGET=""ve-linux"" \
    -DCMAKE_CXX_COMPILER_TARGET=""ve-linux"" \
    -DCMAKE_BUILD_TYPE="Release" \
    -DCMAKE_INSTALL_PREFIX=""""/scratch/buildbot/bothome/clang-ve-ninja/build/build_llvm""/lib/clang/15.0.0"" \
    -DLIBUNWIND_LIBDIR_SUFFIX="/linux/ve" \
    -DCMAKE_CXX_FLAGS="-nostdlib" \
    -DCMAKE_CXX_FLAGS_RELEASE="-O2" \
    -DCMAKE_C_FLAGS="-nostdlib" \
    -DCMAKE_C_FLAGS_RELEASE="-O2" \
    -DLIBUNWIND_LIBCXX_PATH=/scratch/buildbot/bothome/clang-ve-ninja/build/../llvm-project/libcxx \
    -DLLVM_PATH=/scratch/buildbot/bothome/clang-ve-ninja/build/../llvm-project/llvm

Instead, you want to be doing something like this:

cmake -S llvm-project/runtimes -B <BUILD_DIR> -G Ninja \
    -DLIBUNWIND_TARGET_TRIPLE=""ve-linux"" \
    -DCMAKE_C_COMPILER="<whatever>" \
    -DCMAKE_CXX_COMPILER="<whatever>" \
    -DCMAKE_AR="<whatever>" \
    -DCMAKE_RANLIB=""<whatever>" \
    -DCMAKE_C_COMPILER_TARGET="ve-linux" \
    -DCMAKE_CXX_COMPILER_TARGET="ve-linux" \
    -DCMAKE_BUILD_TYPE="Release" \
    -DCMAKE_INSTALL_PREFIX="<whatever>" \
    -DLIBUNWIND_LIBDIR_SUFFIX="/linux/ve" \
    -DCMAKE_CXX_FLAGS="-nostdlib" \
    -DCMAKE_CXX_FLAGS_RELEASE="-O2" \
    -DCMAKE_C_FLAGS="-nostdlib" \
    -DCMAKE_C_FLAGS_RELEASE="-O2" \
    -DLLVM_ENABLE_RUNTIMES="libunwind"

So basically, use <monorepo>/runtimes as the root of the CMake tree, drop LIBUNWIND_LIBCXX_PATH and LLVM_PATH, and add -DLLVM_ENABLE_RUNTIMES="libunwind".

Thanks. We are testing this now and will switch to a runtimes build soon.

[mgorny]

For the record, I just want to say that this sucks a lot for Gentoo and I'm really unhappy with the recent trend of ignoring other people's effort and destroying their use cases for one's own convenience. But I guess I have to live with it. It's just sad how much effort I've wasted fixing things every time standalone builds were broken, and in the end the working code is being broken for the sake of preventing others from maintaining standalone builds. In the end, we'll manage but probably at the cost of preventing our users from installing GNU libunwind and libc++ simultaneously but I guess people using binary distros just don't care that could be a better way.

[serge-sans-paille]

Standalone build have been deprecated for some time now,

@ldionne : can you point me to the thread / documentation that states so? I can find https://discourse.llvm.org/t/standalone-build-for-clang-lld-fix-or-remove but this thread doesn't lead me to the same conclusion.

[efriedma]

See https://lists.llvm.org/pipermail/llvm-dev/2021-October/153238.html for context.

[ldionne]

In D119255#3310444, @simoll wrote:

Thanks. We are testing this now and will switch to a runtimes build soon.

Sure! Let me know if you run into issues with this. Remember, you want to be rooting your CMake invocation at <monorepo>/runtimes, not <monorepo>/llvm. The former is going to build similarly to the previous standalone build, and the latter would cause Clang to be bootstrapped first, which is a bigger change from what you were doing previously.

In D119255#3310667, @mgorny wrote:

For the record, I just want to say that this sucks a lot for Gentoo and I'm really unhappy with the recent trend of ignoring other people's effort and destroying their use cases for one's own convenience. But I guess I have to live with it. It's just sad how much effort I've wasted fixing things every time standalone builds were broken, and in the end the working code is being broken for the sake of preventing others from maintaining standalone builds. In the end, we'll manage but probably at the cost of preventing our users from installing GNU libunwind and libc++ simultaneously but I guess people using binary distros just don't care that could be a better way.

I'm going to stay nice despite the accusatory tone of your message.

This change has been cooking for a long time, just like the upcoming removal of LLVM_ENABLE_PROJECTS for libcxx, libcxxabi and libunwind. This is not about "convenience" or breaking people just for the sake of it, as this commit might make you think. The reason why this commit is just adding message(FATAL_ERROR is because I wanted to keep the cleanup that will follow separate, in case this needed to be reverted.

Standalone builds are a pain to maintain. We need to tie the various projects together with a bunch of CMake variables, which adds a bunch of complexity. Instead, it's much easier if we can assume that things are laid out in a specific way in the repository. We'll be able to reuse a bunch of code for all the runtimes, and as a result make things simpler, easier to maintain and even more customizable in the future. I already have a bunch of ideas that can't be implemented right now because we'd have to triplicate the code in libcxx, libcxxabi and libunwind, which is just terrible.

Also, there is a common misconception about the removal of standalone builds. Removing standalone builds DOES NOT MEAN that we remove any customizability in your builds. You can still build just one project, nothing changes here. Please go and read our documentation on the supported ways to build: https://libcxx.llvm.org/BuildingLibcxx.html#the-default-build. If you want to build just libcxx, you can always do this:

cmake -G Ninja -S <monorepo>/runtimes -B build -DLLVM_ENABLE_RUNTIMES="libcxx"
ninja -C build cxx

(You'll need to pass the usual options for specifying the ABI library to use unless you also add libcxxabi to LLVM_ENABLE_RUNTIMES)

This is basically the same as a standalone build -- it doesn't build Clang, it doesn't build libc++abi, it doesn't build libunwind. It builds libc++ only, and gives you exactly the same control you had before on your build. If you want to build libc++abi or libunwind separately, you can run three of these builds with a different LLVM_ENABLE_RUNTIMES=<foo> each time, like you do for standalone builds. It's cumbersome to do that, but nobody's going to stop you. If there is some customizability you think you are losing with the new way to build, please let me know concretely what it is, and we'll try to support it. But I don't think there should be anything that you could do with standalone builds that you can't do anymore, except laying out the projects in arbitrary ways (but dropping support for that is the whole point, since it's hard to support and provides virtually no benefit).

In D119255#3312150, @serge-sans-paille wrote:

Standalone build have been deprecated for some time now,

@ldionne : can you point me to the thread / documentation that states so? I can find https://discourse.llvm.org/t/standalone-build-for-clang-lld-fix-or-remove but this thread doesn't lead me to the same conclusion.

There was discussion about this in 2020 here, and then various patches by @phosek, myself and others over the last 1.5 years to work towards what we're finally doing today. The direction we ended up taking for the "unified standalone build" is basically what you do when you root the CMake invocation at <monorepo>/runtimes.

[ldionne]

In D119255#3312321, @efriedma wrote:

See https://lists.llvm.org/pipermail/llvm-dev/2021-October/153238.html for context.

Oh yes, there's that one too, thanks.

[mgorny]

I'm sorry about my tone and thank you for the explanation.

[ldionne]

In D119255#3313815, @mgorny wrote:

I'm sorry about my tone and thank you for the explanation.

No worries. Migrations tend to cause tensions by their very nature. I saw you opened a couple of patches to fix some quirks with the new way to build. Thanks -- I'm looking forward to collaborating to make sure we're still addressing Gentoo's use cases (and others) in a satisfactory way.

libcxx/CMakeLists.txt

 
 set(CMAKE_FOLDER "libc++")
 
 set(LIBCXX_SOURCE_DIR  ${CMAKE_CURRENT_SOURCE_DIR})
 set(LIBCXX_BINARY_DIR  ${CMAKE_CURRENT_BINARY_DIR})
 set(LIBCXX_BINARY_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++build")
 
 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR LIBCXX_STANDALONE_BUILD)
+  message(FATAL_ERROR "The Standalone build has been deprecated since LLVM 14, and it is not supported anymore. "
+                      "Please use one of the ways described at https://libcxx.llvm.org/BuildingLibcxx.html for "
+                      "building libc++.")
   project(libcxx CXX C)
 
   set(PACKAGE_NAME libcxx)
   set(PACKAGE_VERSION 15.0.0git)
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
   set(PACKAGE_BUGREPORT "[e-mail]")
 
   # In a standalone build, we don't have llvm to automatically generate the

libcxx/docs/ReleaseNotes.rst

 
 - The ``_LIBCPP_ABI_USE_CXX03_NULLPTR_EMULATION`` macro controlling whether we use an
   emulation for ``std::nullptr_t`` in C++03 mode has been removed. After this change,
   ``_LIBCPP_ABI_USE_CXX03_NULLPTR_EMULATION`` will not be honoured anymore and there
   will be no way to opt back into the C++03 emulation of ``std::nullptr_t``.
 
 Build System Changes
 --------------------
+
+- Support for standalone builds have been entirely removed from libc++, libc++abi and
+  libunwind. Please use `these instructions <https://libcxx.llvm.org/BuildingLibcxx.html>`_
+  for building libc++, libc++abi and/or libunwind.

libcxx/utils/ci/buildkite-pipeline.yml

- label: "Legacy Lit configuration"
         queue: "libcxx-builders"
         os: "linux"
       retry:
         automatic:
           - exit_status: -1  # Agent was lost
             limit: 2
       timeout_in_minutes: 120
 
-    - label: "Legacy standalone build"
-      command: "libcxx/utils/ci/run-buildbot legacy-standalone"
-      artifact_paths:
-        - "**/test-results.xml"
-      agents:
-        queue: "libcxx-builders"
-        os: "linux"
-      retry:
-        automatic:
-          - exit_status: -1  # Agent was lost
-            limit: 2
-      timeout_in_minutes: 120
-
     - label: "Legacy LLVM_ENABLE_PROJECTS build"
       command: "libcxx/utils/ci/run-buildbot legacy-project-build"
       artifact_paths:
         - "**/test-results.xml"
       agents:
         queue: "libcxx-builders"
         os: "linux"
       retry:

libcxx/utils/ci/run-buildbot

${CMAKE} \
           -DLLVM_ENABLE_PROJECTS="libcxx;libunwind;libcxxabi" \
           -GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
           -DCMAKE_BUILD_TYPE=RelWithDebInfo \
           -DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
           -DLLVM_LIT_ARGS="-sv --show-unsupported --xunit-xml-output test-results.xml" \
           -DLIBCXX_CXX_ABI=libcxxabi
     check-runtimes
 ;;
-legacy-standalone)
-    clean
-
-    echo "--- Generating CMake"
-    ${CMAKE} \
-          -S "${MONOREPO_ROOT}/libcxx" \
-          -B "${BUILD_DIR}/libcxx" \
-          -GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
-          -DCMAKE_BUILD_TYPE=RelWithDebInfo \
-          -DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
-          -DLLVM_PATH="${MONOREPO_ROOT}/llvm" \
-          -DLIBCXX_CXX_ABI=libcxxabi \
-          -DLIBCXX_INCLUDE_BENCHMARKS=OFF \
-          -DLIBCXX_CXX_ABI_INCLUDE_PATHS="${MONOREPO_ROOT}/libcxxabi/include" \
-          -DLIBCXX_CXX_ABI_LIBRARY_PATH="${BUILD_DIR}/libcxxabi/lib"
-
-    ${CMAKE} \
-          -S "${MONOREPO_ROOT}/libcxxabi" \
-          -B "${BUILD_DIR}/libcxxabi" \
-          -GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
-          -DCMAKE_BUILD_TYPE=RelWithDebInfo \
-          -DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
-          -DLLVM_PATH="${MONOREPO_ROOT}/llvm" \
-          -DLIBCXXABI_LIBCXX_PATH="${MONOREPO_ROOT}/libcxx" \
-          -DLIBCXXABI_LIBCXX_INCLUDES="${BUILD_DIR}/libcxx/include/c++/v1" \
-          -DLIBCXXABI_LIBCXX_LIBRARY_PATH="${BUILD_DIR}/libcxx/lib"
-
-    echo "+++ Generating libc++ headers"
-    ${NINJA} -vC "${BUILD_DIR}/libcxx" generate-cxx-headers
-
-    echo "+++ Building libc++abi"
-    ${NINJA} -vC "${BUILD_DIR}/libcxxabi" cxxabi
-
-    echo "+++ Building libc++"
-    ${NINJA} -vC "${BUILD_DIR}/libcxx" cxx
-
-    echo "+++ Running the libc++ tests"
-    ${NINJA} -vC "${BUILD_DIR}/libcxx" check-cxx
-
-    echo "+++ Running the libc++abi tests"
-    ${NINJA} -vC "${BUILD_DIR}/libcxxabi" check-cxxabi
-;;
 aarch64)
     clean
     generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/AArch64.cmake" \
                    -DLIBCXX_TEST_CONFIG="llvm-libc++-shared.cfg.in" \
                    -DLIBUNWIND_TEST_CONFIG="llvm-libunwind-shared.cfg.in"
     check-runtimes
 ;;
 aarch64-noexceptions)

libcxxabi/CMakeLists.txt

 set(CMAKE_FOLDER "libc++")
 
 set(LIBCXXABI_SOURCE_DIR  ${CMAKE_CURRENT_SOURCE_DIR})
 set(LIBCXXABI_BINARY_DIR  ${CMAKE_CURRENT_BINARY_DIR})
 set(LIBCXXABI_LIBCXX_PATH "${CMAKE_CURRENT_LIST_DIR}/../libcxx" CACHE PATH
         "Specify path to libc++ source.")
 
 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR LIBCXXABI_STANDALONE_BUILD)
+  message(FATAL_ERROR "The Standalone build has been deprecated since LLVM 14, and it is not supported anymore. "
+                      "Please use one of the ways described at https://libcxx.llvm.org/BuildingLibcxx.html for "
+                      "building libc++abi.")
+
   project(libcxxabi CXX C)
 
   set(PACKAGE_NAME libcxxabi)
   set(PACKAGE_VERSION 11.0.0git)
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
   set(PACKAGE_BUGREPORT "[e-mail]")
 
   set(LIBCXXABI_STANDALONE_BUILD TRUE)

libcxxabi/www/index.html

<div id="content">
 
    <p>libc++abi is complete.  <a href="spec.html">Here</a> is a
    list of functionality.</p>
 
   <!--=====================================================================-->
   <h2>Get it and get involved!</h2>
   <!--=====================================================================-->
 
-  <p>To check out the code (including llvm and others), use:</p>
-
-  <ul>
-  <li><code>git clone https://github.com/llvm/llvm-project.git</code></li>
-  </ul>
-
-  <p>To build:</p>
-  <ul>
-  <li><code>cd llvm-project</code></li>
-  <li><code>mkdir build &amp;&amp; cd build</code></li>
-  <li><code>cmake -DLLVM_ENABLE_PROJECTS=libcxxabi ../llvm # on linux you may need to specify -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++</code></li>
-  <li><code>make</code></li>
-  </ul>
-
-  <p>To do a standalone build:</p>
-  <ul>
-  <li>
-    Check out the source tree. This includes the other subprojects, but you'll only use the libcxxabi part.
-  </li>
-  <li><code>cd llvm-project</code></li>
-  <li><code>mkdir build-libcxxabi &amp;&amp; cd build-libcxxabi</code></li>
-  <li><code>cmake ../libcxxabi # on linux you may need -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++</code></li>
-  <li><code>make</code></li>
-  </ul>
-  <p> By default CMake uses <code>llvm-config</code> to locate the required
-      LLVM sources. If CMake cannot find <code>llvm-config</code> then you must
-      configure CMake using either of the following options.
-  </p>
-  <ul>
-  <li><code>-DLLVM_CONFIG_PATH=path/to/llvm-config</code></li>
-  <li><code>-DLLVM_PATH=path/to/llvm-source-root</code></li>
-  </ul>
-
-  </p>
-
-  <p>To run the tests:</p>
-  <ul>
-  <li><code>make check-cxxabi</code></li>
-  </ul>
-  <p>Note: in a standalone build, the system's libc++ will be used for tests. If
-  the system's libc++ was statically linked against libc++abi (or linked against
-  a different ABI library), this may interfere with test results.</p>
-
-  <p>Send discussions to the
-  (<a href="https://lists.llvm.org/mailman/listinfo/libcxx-dev">libcxx-dev mailing list</a>).</p>
+  <p>Please see the <a href="https://libcxx.llvm.org">libc++ documentation</a>.</p>
 
   <!--=====================================================================-->
   <h2>Frequently asked questions</h2>
   <!--=====================================================================-->
 
   <p>Q: Why are the destructors for the standard exception classes defined in libc++abi?
      They're just empty, can't they be defined inline?</p>
   <p>A: The destructors for them live in libc++abi because they are "key" functions.

libunwind/CMakeLists.txt

list(INSERT CMAKE_MODULE_PATH 0
   )
 
 set(LIBUNWIND_SOURCE_DIR  ${CMAKE_CURRENT_SOURCE_DIR})
 set(LIBUNWIND_BINARY_DIR  ${CMAKE_CURRENT_BINARY_DIR})
 set(LIBUNWIND_LIBCXX_PATH "${CMAKE_CURRENT_LIST_DIR}/../libcxx" CACHE PATH
         "Specify path to libc++ source.")
 
 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR LIBUNWIND_STANDALONE_BUILD)
+  message(FATAL_ERROR "The Standalone build has been deprecated since LLVM 14, and it is not supported anymore. "
+                      "Please use one of the ways described at https://libcxx.llvm.org/BuildingLibcxx.html for "
+                      "building libunwind.")
+
   # We may have an incomplete toolchain - do language support tests without
   # linking.
   include(EnableLanguageNolink)
   project(libunwind LANGUAGES NONE)
 
   set(PACKAGE_NAME libunwind)
   set(PACKAGE_VERSION 15.0.0git)
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")