[PATCH] D107799: [CMake] Enable LLVM_ENABLE_PER_TARGET_RUNTIME_DIR by default on most platforms

Chris Bieneman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 11 08:27:31 PDT 2021


beanz added subscribers: steven_wu, arphaman.
beanz added a comment.

In D107799#2938302 <https://reviews.llvm.org/D107799#2938302>, @tstellar wrote:

> Is there any reason why the prefix couldn't be lib/clang/14/ instead of lib/clang/14.0.0/ ?

I think keeping the full version number is good in case we rev any of the headers or libraries shipped with clang in a patch release. It is good to be able to ensure those directories don't overlap or have stale contents if clang gets installed into the same root directory.

In D107799#2938070 <https://reviews.llvm.org/D107799#2938070>, @phosek wrote:

> That would better match other platforms, but I'd like to hear from Apple folks like @beanz whether this is something that would make sense.

I'm probably not the best person from Apple to weigh in here since I'm not actively involved with clang toolchains anymore. @steven_wu & @arphaman are probably better people to consult since they'd need to be involved.

I always thought it would be best to get Darwin to start building thin-archives for all the compiler-rt libraries, and to move to triple-based directory structure. There's no reason the compiler can't operate on thin files, and it would allow much of the driver and build system code to become unified. Which would be a huge win.

I suspect part of how we got to the place we're at now is because the driver doesn't share a lot of code between targets, and back in the old makefile days each target basically had its own makefiles for compiler-rt. CMake always tried to share logic, but became a mess trying to do _very_ different things.

It would be a big project to clean up and unify all of that, but totally worth doing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107799



More information about the llvm-commits mailing list