[PATCH] D51986: Fixes for `LLVM_LINK_LLVM_DYLIB` && Polly.

[Richard Diamond via Phabricator via cfe-commits]

DiamondLovesYou added a comment.

In https://reviews.llvm.org/D51986#1232320, @beanz wrote:

> I don’t think this is the right solution. The build system knows what components are in the dylib and should remove them from the list of libraries linked individually. You should be able to make Polly behave like an LLVM component, then tools don’t need to care if the dylib is used or not.


That's not true if `target_link_libraries(${target} _whatever_ ${libs})` is used. That function will pull in all of each of `${libs}`' dependencies, which causes problems because then, eg, `bugpoint` will then be linked with `libLLVM.so` (as expected) AND `libPolly.a` (assuming `BUILD_SHARED_MODULES` is false) AND then a bunch of LLVM components. The LLVM components (including Polly) will then conflict with `libLLVM.so`.

Polly already enjoys status as an LLVM component. No effort was necessary to include Polly in `libLLVM.so` for example.


Repository:
  rC Clang

https://reviews.llvm.org/D51986