[libc++] Do not install the C++ ABI library's headers as part of libc++'s build

[ldionne]

Summary

It's the role of the C++ ABI library to install its own headers, not libc++.
This fixes an existing issue causing spurious CI failures where both libc++
and libc++abi would try to install <cxxabi.h> & friends in the same location,
leading to failures during the installation step.

[ldionne]

Pinging libc++ vendors for awareness, since there is an action item for folks who build with a custom ABI library.

[ldionne]

I'll land this tomorrow morning so I can watch out for any potential fallout.

libcxx/cmake/Modules/HandleLibCXXABI.cmake

 # Parameters:
 #   abidefines: A list of defines needed to compile libc++ with the ABI library
 #   abishared : The shared ABI library to link against.
 #   abistatic : The static ABI library to link against.
 #   abifiles  : A list of files (which may be relative paths) to copy into the
 #               libc++ build tree for the build.  These files will be copied
 #               twice: once into include/, so the libc++ build itself can find
 #               them, and once into include/c++/v1, so that a clang built into
-#               the same build area will find them.  These files will also be
-#               installed alongside the libc++ headers.
+#               the same build area will find them.
 #   abidirs   : A list of relative paths to create under an include directory
 #               in the libc++ build directory.
 #
 
 macro(setup_abi_lib abidefines abishared abistatic abifiles abidirs)
   list(APPEND LIBCXX_COMPILE_FLAGS ${abidefines})
   set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_CXX_ABI_INCLUDE_PATHS}"
     CACHE PATH
foreach(incpath ${LIBCXX_CXX_ABI_INCLUDE_PATHS})
         # TODO: libc++ shouldn't be responsible for copying the libc++abi
         # headers into the right location.
         set(dst "${LIBCXX_GENERATED_INCLUDE_DIR}/${dstdir}/${fpath}")
         add_custom_command(OUTPUT ${dst}
             DEPENDS ${src}
             COMMAND ${CMAKE_COMMAND} -E copy_if_different ${src} ${dst}
             COMMENT "Copying C++ ABI header ${fpath}...")
         list(APPEND abilib_headers "${dst}")
-
-        if (LIBCXX_INSTALL_HEADERS)
-          install(FILES "${LIBCXX_BINARY_INCLUDE_DIR}/${fpath}"
-            DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/c++/v1/${dstdir}"
-            COMPONENT cxx-headers
-            PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-            )
-        endif()
       else()
         message(STATUS "Looking for ${fpath} in ${incpath} - not found")
       endif()
     endforeach()
     if (NOT found)
       message(WARNING "Failed to find ${fpath} in ${LIBCXX_CXX_ABI_INCLUDE_PATHS}")
     endif()
   endforeach()

libcxx/docs/ReleaseNotes.rst

- The ``{LIBCXX,LIBCXXABI,LIBUNWIND}_TARGET_TRIPLE``, ``{LIBCXX,LIBCXXABI,LIBUNWIND}_SYSROOT`` and
   ``{LIBCXX,LIBCXXABI,LIBUNWIND}_GCC_TOOLCHAIN`` CMake variables have been removed. Instead, please
   use the ``CMAKE_CXX_COMPILER_TARGET``, ``CMAKE_SYSROOT`` and ``CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN``
   variables provided by CMake.
 
 - When building for Windows, vendors who want to avoid dll-exporting symbols from the static libc++abi
   library should set ``LIBCXXABI_HERMETIC_STATIC_LIBRARY=ON`` when configuring CMake. The current
   behavior, which tries to guess the correct dll-export semantics based on whether we're building
   the libc++ shared library, will be removed in LLVM 16.
+
+- Previously, the C++ ABI library headers would be installed inside ``<prefix>/include/c++/v1``
+  alongside the libc++ headers as part of building libc++. This is not the case anymore -- the
+  ABI library is expected to install its headers where it wants them as part of its own build.
+  Note that no action is required for most users, who build libc++ against libc++abi, since
+  libc++abi already installs its headers in the right location. However, vendors building
+  libc++ against alternate ABI libraries should make sure that their ABI library installs
+  its own headers.