This is an archive of the discontinued LLVM Phabricator instance.

[lld] Boot bitrotting add_lld_library() from CMake build
ClosedPublic

Authored by garious on Jan 20 2015, 2:02 PM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

garious updated this revision to Diff 18459.Jan 20 2015, 2:02 PM
garious retitled this revision from to [lld] Boot bitrotting add_lld_library() from CMake build.
garious updated this object.
garious edited the test plan for this revision. (Show Details)
garious set the repository for this revision to rL LLVM.
garious added a project: lld.
garious added a subscriber: Unknown Object (MLST).
chandlerc edited edge metadata.Jan 20 2015, 2:09 PM

If we go this route, we should just replace the usages of the macro.

garious updated this revision to Diff 18463.Jan 20 2015, 3:07 PM
garious edited edge metadata.

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:

  1. 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...
  1. 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).

rafael edited edge metadata.Jan 21 2015, 6:02 AM
  1. 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.

garious updated this revision to Diff 18537.Jan 21 2015, 10:55 AM
garious edited edge metadata.

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.

rafael accepted this revision.Jan 21 2015, 12:54 PM
rafael edited edge metadata.

I checked that the names are correct (no LLVMlldConfig).

LGTM.

This revision is now accepted and ready to land.Jan 21 2015, 12:54 PM
chandlerc accepted this revision.Jan 21 2015, 1:10 PM
chandlerc edited edge metadata.

LGTM as well.

garious closed this revision.Jan 21 2015, 1:29 PM

Committed in r226702. Thanks!