New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
relative refstring.h include in libcxxabi makes too strong assumptions #48657
Comments
Oh, https://reviews.llvm.org/D91359 adds an include of another internal header to refstring.h, so if we were to revert we'd have to copy that too. That doesn't seem great. So maybe using |
See also LIBCXXABI_LIBCXX_INCLUDES for a cmake toggle for the public includes. |
Libc++ and libc++abi have required being built in a monorepo-like layout for a while now. We have a strong desire to share more code between libc++ and libc++abi (in particular some CMake code), so I don't see us going back to allowing libc++/abi being built from arbitrary locations. Can you tell me a bit more about your setup? If you're currently storing libc++ and libc++abi in |
This is the only thing requiring this at the source level. LIBCXXABI_STANDALONE_BUILD still exists, too.
Sure! We don't want to deps in all of llvm into our build, but only the runtime bits (actually, only libcxx, libcxxabi, and libunwind). So we have git mirrors of those subtrees. We then deps in each of these subtrees at t_p/depname/src and have a build file for each at t_p/depname/buildfile.
That'd mean we can't independently roll libcxx, libcxxabi, and libunwind. ...would something like the following work for you? That keeps things basically the same upstream and makes things easier for us: $ git diff include_directories("${LIBCXXABI_LIBCXX_INCLUDES}") +# stdlib_stdexcept.cpp depends on libc++ internals. -#include "../../libcxx/src/include/refstring.h" +// This is a file form libc++. namespace std // purposefully not using versioning namespace |
Uploaded basically that diff to https://reviews.llvm.org/D97379 |
Extended Description
a7b6574 (unreviewed? at least doesn't link to phab) adds this line to libc++abi's libcxxabi/src/stdlib_stdexcept.cpp:
+#include "../../libcxx/src/include/refstring.h"
This assumes a certain relative layout, which happens to not be the layout we have libc++ and libc++abi relative to in chromium. It's also not very easy to change things to give them that layout -- many third-party directories in chromium put code in "t_p/depname/src" (via a git submodules like thing) and then
put a build file in "t_p/depname".
We're trying to update our libc++abi now that we've successfully updated our libc++, and this is a problem.
We could add a random -I flag that this relative path resolves against. I'll do this for now, but it's a bit ugly. Maybe we can find something nicer to do on this bug.
Options:
#include "refstring.h"
and set up the include path in the build systemThe text was updated successfully, but these errors were encountered: