This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.
Details
- Reviewers
smeenai beanz jdenny EricWF - Commits
- rCXXA355665: [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/
rUNW355665: [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/
rCXX355665: [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/
rG28302c66d258: [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/
rC355665: [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/
rL355665: [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/
Diff Detail
Event Timeline
libcxx/CMakeLists.txt | ||
---|---|---|
421 | This is a bit of a hack, we allow building runtimes with sanitizer instrumentation and we install those sanitized versions into lib/<target>/<sanitizer>, e.g. lib/x86_64-fuchsia/asan. Those are never linked against (the ABI should be the same as for the non-sanitized version), they're only intended for packaging, hence the missing driver logic. We use the <RUNTIME>_LIBDIR_SUFFIX to set the <sanitizer> portion of the install path, see https://github.com/llvm/llvm-project/blob/master/llvm/runtimes/CMakeLists.txt#L517. However, if anyone ever tries to use both the LIBDIR_SUFFIX and instrumentation, things are going to break. Maybe we should introduce another variable for this, e.g. <RUNTIME>_LIBDIR_VARIANT? |
clang/test/Driver/linux-per-target-runtime-dir.c | ||
---|---|---|
13 | Shouldn't this one be different now? | |
libcxx/CMakeLists.txt | ||
421 | It's expected for LIBCXX_LIBDIR_SUBDIR to always begin with a /, correct? I feel like it would be less error-prone to have places using that variable add the / rather than relying on the variable containing it. In particular, since the variable name contains SUBDIR, I wouldn't expect to have to specify the leading / of the subdirectory myself. Case in point: if I'm reading correctly, DEFAULT_INSTALL_PREFIX will end with a trailing /, and then LIBCXX_INSTALL_LIBDIR will begin with a leading /, so you'll end up with two consecutive / when you join the two in lib/CMakeLists.txt. Not a big deal, but also easily avoidable, I think. |
libcxx/CMakeLists.txt | ||
---|---|---|
420–421 | Yes, this is something I actually introduced in previous iterations of the runtimes build efforts. We could consider deleting them altogether, but I don't know how to find out if there are any users of these. I could send an email to libcxx-dev and see if anyone responds. |
Is this supposed to append lib twice?