LGTM, this looks great, I think we should do the same for libc++abi and libunwind. I've added @smeenai since he has CMake expertise.

In D59168#1424968, @smeenai wrote:

I don't think the duplicated triple is too huge of a deal. I think the layout where the resource directory is moved inside the triple directory is a bit nicer, but I also don't know how much work that change would be and if it's worth it.

This seems to be failing on our Mac bots for some reason:

The layout currently looks as follows:

This is a reland of D59013, apart from fixing the failing test on Windows, it also changes one thing where libraries are installed in lib/clang/<target> rather than lib/<target> based on the discussion in "RFC: Place libs in Clang-dedicated directories (affects openmp, libcxx, libunwind, compiler-rt)".
"

LGTM

I've updated the patch to make the .build-id linking an option that can be set in the cache file, how does that look to you?

This broke the 2-stage LTO build of LLVM, the error is:

ld.lld: /usr/local/google/home/phosek/clang-llvm/llvm-project/llvm/lib/IR/Constants.cpp:995: static llvm::Constant *llvm::ConstantArray::getImpl(llvm::ArrayType *, ArrayRef<llvm::Constant *>): Assertion `V[i]->getType() == Ty->getElementType() && "Wrong type in array element initializer"' failed.

In D59120#1422341, @jakehehrlich wrote:

Would be nice to have a test where 2 sections are out of order, and this change puts them into the correct order. It's not clear from this if the build ID section is naturally placed at the end or not.

@joerg is it okay with you if I go ahead and land this?

LGTM

In D58374#1411376, @chandlerc wrote:

Maybe update at least some of the tests using these targets to additionally run with the new pass manager explicitly enabled via flag?

In D28791#1414044, @matthewbauer wrote:

I was trying to build compiler-rt with WebAssembly and forgot I still had this patched applied. But it looks like it breaks when doing this and things work if you disble crt. You probably just don't want to build crt with WebAssembly targets?

LGTM

In D58533#1413078, @eugenis wrote:

r355064 should do this.

This broke our builders with the following error:

Done in D58745.

In D57872#1397674, @EricWF wrote:

combining these together in LIBCXX_LIBRARIES and LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies.

Can you provide an example? And elaborate on the introducing unused libraries on the link line?

Ping?

Ping?

In D28791#1357948, @joerg wrote:

For the clang side, I don't understand why Driver::GetFilePath is not good enough. This shouldn't need all toolchain changes at all.

In D58317#1404966, @smeenai wrote:

In D58317#1404961, @phosek wrote:

In D58317#1400223, @smeenai wrote:

I'm not entirely happy with the name clang-dev-headers, and am open to suggestions. It's unfortunate clang-headers was already taken for something different, but renaming that target or increasing its scope seems bad for existing users. Other possibilities I thought of include clang-tooling-headers, though that might be confused with the headers for libTooling specifically, and clang-library-headers. I'm open to suggestions.

We could consider renaming clang-headers to e.g. clang-resource-headers and then reusing the name which would match llvm-headers. What do you think about that?

I like that, but I'm worried about breaking existing users of the clang-headers target (e.g. in their build scripts or distributions). I could post on cfe-dev and wait for dissent/consensus, I guess, but if there's an option which doesn't involve breaking backward compatibility, maybe that's preferable.

In D58317#1400223, @smeenai wrote:

I'm not entirely happy with the name clang-dev-headers, and am open to suggestions. It's unfortunate clang-headers was already taken for something different, but renaming that target or increasing its scope seems bad for existing users. Other possibilities I thought of include clang-tooling-headers, though that might be confused with the headers for libTooling specifically, and clang-library-headers. I'm open to suggestions.

LGTM