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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
