[libcxx-commits] [PATCH] D101458: [libc++] Do not copy the libc++abi headers into the libc++ build tree

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D101458#2723626 <https://reviews.llvm.org/D101458#2723626>, @thakis wrote:

> Makes sense to me.
>
> Just to confirm: Even back when clang assumed that libc++ headers shipped with the compiler instead of the sdk on macOS (which I think is still the case in currently shipping xcode), it didn't assume that the libc++abi headers ship with the compiler, right? (I patched this in and clang still seems to compile a program that includes <iostream> fine, so it looks like it.)

Fact: Clang used to assume that libc++ was shipped in `<toolchain>/include/c++/v1`, and nowadays it looks in `<sdk>/include/c++/v1` first, and only falls back to `<toolchain>/include/c++/v1`.
Fact: Recent SDKs have the libc++ headers in `<sdk>/usr/include/c++/v1`.
Fact: The `<cxxabi.h>` header is present in both `<sdk>/usr/include/c++/v1` and `<sdk>/usr/include` (and also in `<toolchain>/usr/include/c++/v1` until we remove all traces of libc++/libc++abi from the toolchain). It looks like they are always the same thing. It's harmless but silly, since we should really have only one copy. It turns out I don't understand how the copy in `<sdk>/usr/include` ends up there, so I'll investigate that.

Your main question: I'm pretty sure Clang used to expect `<cxxabi.h>` in `<toolchain>/usr/include/c++/v1`, alongside the rest of libc++.

I actually hadn't realized that, and it does change what I was going to do. Instead of always installing `<cxxabi.h>` to `<install>/usr/include`, I think the correct thing to do would be to always install it to `<install>/usr/include/c++/v1`, but to do that directly from libc++abi. My next update will reflect that.



================
Comment at: libcxx/cmake/Modules/HandleLibCXXABI.cmake:15
 
 macro(setup_abi_lib abidefines abishared abistatic abifiles abidirs)
   list(APPEND LIBCXX_COMPILE_FLAGS ${abidefines})
----------------
phosek wrote:
> We should also consider inlining this macro, I don't think it's getting us anything and I always have to lookup what each argument does so at least in my experience it harms readability.
Oh yeah, totally, I want to clean up this mess, one step at a time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101458