[libcxx-commits] [PATCH] D89041: [libc++] Include <__config_site> from <__config>

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a subscriber: thakis.
ldionne added a comment.

In D89041#2349186 <https://reviews.llvm.org/D89041#2349186>, @mstorsjo wrote:

> Yes, that does indeed seem to work; I first configure libcxx and build the `generate-cxx-headers` target, then configure libcxxabi, pointing it at the libcxx build dir's `<build>/include/c++/v1` directory and build libcxxabi, then finally build libcxx. (I can also build the `install-cxx-headers` target and point libcxxabi at `<installprefix>/include/c++/v1`.) As a bonus, this also seems to work the same with the 11 stable release. (If possible, I want to be able to build both the latest stable release and the current master with the same setup.)
>
> I'll have a look at your unified standalone setup as well - it sounds like it could clean up a lot of issues like these and also get rid of a number of sharp edges and reliance on kinda internal details in how I build libunwind+libcxxabi+libcxx together right now.

Yes, this +10000. At this point, it's 100% clear to  me we need to drop support for the classic standalone builds -- they are just too tricky to maintain, and that's not good for anyone. FWIW, here's the setup I use for testing standalone builds locally:

  rm -rf "${BUILD_DIR}/libcxx" "${BUILD_DIR}/libcxxabi" "${INSTALL_DIR}"
  mkdir -p "${BUILD_DIR}/libcxx" "${BUILD_DIR}/libcxxabi" "${INSTALL_DIR}"
  
  (cd "${BUILD_DIR}/libcxx" &&
      cmake "${LIBCXX_ROOT}" -GNinja \
                             -DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
                             -DLLVM_PATH="${LLVM_ROOT}" \
                             -DLIBCXX_INCLUDE_TESTS=ON \
                             -DLIBCXX_CXX_ABI=libcxxabi \
                             -DLIBCXX_CXX_ABI_INCLUDE_PATHS="${LIBCXXABI_ROOT}/include")
  
  (cd "${BUILD_DIR}/libcxxabi" &&
      cmake "${LIBCXXABI_ROOT}" -GNinja \
                                -DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
                                -DLLVM_PATH="${LLVM_ROOT}" \
                                -DLIBCXXABI_INCLUDE_TESTS=ON \
                                -DLIBCXXABI_LIBCXX_PATH="${LIBCXX_ROOT}" \
                                -DLIBCXXABI_LIBCXX_INCLUDES="${BUILD_DIR}/libcxx/include/c++/v1")

Notice how I'm passing the build directory's `include/c++/v1` path, not `libcxx/include`. This is still a hack cause that isn't technically the "installed" version of libc++, it's the build-internal one, but whatever for now.

In D89041#2349675 <https://reviews.llvm.org/D89041#2349675>, @mstorsjo wrote:

> Another effect of this change, is that if I'm working on libcxx, have a previously fully built workdir, and e.g. edit a header, and rerun ninja, it will only do one build task (copy the updated header into the build dir's include dir). If I rerun `ninja` again, it will actually rebuild the sources against the newly updated header. So at the ninja level, it's missing a dependency that implies that the copy header phase actually updates files that ninja already tracks the modification date for.

Yeah, I'm seeing that too. Using a minimal setup that's exactly like ours, I see that CMake is doing the right thing, though. This is weird -- it's either a fine subtlety in our setup, or a CMake bug.

**I've decided to revert this change. We're still seeing failures in the runtimes build that I'm unable to reproduce locally, and we need to get the bots green again. It's been two days of scrambling around and trying to fix everything, but it's getting out of control. Now that we know how much ripple effect this change has, I'll split the change up into small bits and check it back in piecemeal.**

@thakis ^ for your GN build


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89041/new/

https://reviews.llvm.org/D89041