add_llvm_library calls llvm_add_library, which works better for shared libraries (sets PRIVATE instead of INTERFACE) and coincidently fixes http://llvm.org/bugs/show_bug.cgi?id=22269 as well.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Per Chandler, use add_llvm_library directly. Also, fix most of the shared library build on OS X. This is as much as I can fix without splitting the ReaderWriter library. I plan to do that right after this patch lands.
Interesting...
So, two high-level comments:
- If you're seriously looking at fixing the layering and build of LLD, please go reply to my email thread about cleaning up its layering. We need some agreed upon target library factoring / layering before trying to move LLD in any direction. I think at least Rui and Nick need to agree on that plan...
- This is highlighting a problem with add_llvm_library that I should have spotted before asking you to use it. Sorry for that. Namely, I don't think it makes sense to have 'LLVMlldConfig' as a library name, and that'll be the result of this approach as far as I understand it.
To address #2 I think we may need to excise some of add_llvm_library'ess logic to make it re-usable, and allow it to override the project name. Or we'll need it to pick up the project prefix from a variable maybe? That might be cleaner. Anyways, we should make it so that these libraries are LLDFoo to compliment the LLVMFoo naming.
To #1: that's why this patch stops here. We can move exactly this far before having that discussion.
To #2: No sign of libLLVMlld* libs here (building on OS X).
- This is highlighting a problem with add_llvm_library that I should have spotted before asking you to use it. Sorry for that. Namely, I don't think it makes sense to have 'LLVMlldConfig' as a library name, and that'll be the result of this approach as far as I understand it.
Note that llvm_add_library is used in clang (from add_clang_library),
so I think the names are handled correctly.
Cheers,
Rafael
Rafael, now that the standalone CMake build is gone, we can assume lld is a subdirectory of the llvm source tree. I'd like to proceed as though the lld will eventually be fully integrated. We therefore do not need the feature of clang's wrapper, which is to retarget the install directory.
Rebased
There will be follow-up patches to continue fixing link-time dependences, but I'd prefer to land this one first to avoid rebasing. It aims to be noncontroversial, whereas experiments in the follow-up patches are starting to look pretty insane. I think it'll have to be broken up into smaller patches as well.