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

[Nico Weber via libcxx-commits]

On Fri, Oct 23, 2020 at 9:30 AM Louis Dionne via Phabricator via
libcxx-commits <libcxx-commits at lists.llvm.org> wrote:

> 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
>

Thanks for the heads-up, but no need to worry about the GN build :) Someone
using it will fix it up soon after you land.

(If you want to revert both bits at once, add reverts
of b3ca53e14274642274be8fe7db8b43dc3c146366
, 8b7dac81d378c339d3e55f6f51cd0c42803903ad
, 37c030f81a9fdd7a7e1b6fa5407b277c1ab1afa1 to your commit -- but as I said,
no need.)


>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D89041/new/
>
> https://reviews.llvm.org/D89041
>
> _______________________________________________
> libcxx-commits mailing list
> libcxx-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-commits/attachments/20201023/fca4be9e/attachment.html>