DiamondLovesYou added a comment. In https://reviews.llvm.org/D51986#1232419, @DiamondLovesYou wrote:
> 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. To add: is there a why to specify optional (as in, link if present) components? 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
