[llvm] r337366 - [CMake] Export the LLVM_LINK_LLVM_DYLIB setting

[Pavel Labath via llvm-commits]

Yes, for that particular configuration it wouldn't work. However, if
one is an external project which does not use clang (for example,
clang itself), then one should be free to choose whether to link to
the monolithic lib or not. (I think, I am now not sure whether the
static libs get installed if you say you want to build the monolithic
dylib)
On Tue, 24 Jul 2018 at 12:49, Philip Pfaffe <philip.pfaffe at gmail.com> wrote:
>
> I haven't tried it yet, but wouldn't that give me duplicate symbols/cl options when linking against libLLVM _and_ a clang library linked statically?
>
> On Tue, Jul 24, 2018 at 1:33 PM Pavel Labath <labath at google.com> wrote:
>>
>> I don't think I know all the implications of this, but would it be
>> possible to export LLVM_**BUILD**_LLVM_DYLIB instead of this option?
>> That way, the external projects will still be able to determine
>> whether the library exists at all, but they will have the option to
>> independently control whether they want to link to it or not?
>> On Tue, 24 Jul 2018 at 11:55, Philip Pfaffe <philip.pfaffe at gmail.com> wrote:
>> >
>> > I can reproduce the not-linking-with-dylib bit, but it doesn't fail during linking for me. That's why I missed this in testing. Sorry!
>> >
>> > Is this serious enough to revert to unbreak you?
>> >
>> > Alternatively there's two quick fixes for this:
>> > - Make LLVM_LINK_LLVM_DYLIB an option() in LLVMConfig.cmake. Then it'll show up in the GUI and respects configurations.
>> > - Wrap the set() in an if().
>> >
>> > I'd prefer going the option() route. Adding a CLANG_LINK_LLVM_DYLIB additionally is worth considering, I'd prefer doing that as a seperate change though.
>> >
>> > Cheers,
>> > Philip
>> >
>> > On Tue, Jul 24, 2018 at 1:30 AM Justin Bogner <mail at justinbogner.com> wrote:
>> >>
>> >> Philip Pfaffe via llvm-commits <llvm-commits at lists.llvm.org> writes:
>> >> > Author: pfaffe
>> >> > Date: Wed Jul 18 01:53:31 2018
>> >> > New Revision: 337366
>> >> >
>> >> > URL: http://llvm.org/viewvc/llvm-project?rev=337366&view=rev
>> >> > Log:
>> >> > [CMake] Export the LLVM_LINK_LLVM_DYLIB setting
>> >> >
>> >> > Summary:
>> >> > When building out-of-tree tools, there are several macros available to
>> >> > automate linking against llvm. An examples is `add_llvm_executable`, or
>> >> > the clang variant of this.
>> >> >
>> >> > These macros use the LLVM_LINK_LLVM_DYLIB option to decide whether to
>> >> > link against libraries defined by setting LLVM_LINK_COMPONENTS or to
>> >> > link against libLLVM instead. Currently this is problematic in
>> >> > out-of-tree targets, because they cannot identify whether this option is
>> >> > required or even available. If the option was enabled in LLVM's own
>> >> > build, the clang libraries are built against libLLVM, so a client
>> >> > linking against those must link against it too. On the other hand the
>> >> > client can't just always link against it, because it might not be
>> >> > available.
>> >>
>> >> I'm not sure I understand the problem this is solving, but it breaks the
>> >> case where an out-of-tree target tries to link the dylib when the
>> >> in-tree build does not. Specifically, if I build llvm with
>> >> LLVM_LINK_LLVM_DYLIB=Off (but LLVM_BUILD_LLVM_DYLIB=On), and then I try
>> >> to build clang against this with LLVM_LINK_LLVM_DYLIB=On, clang's
>> >> setting of the variable seems to be ignored and I get link errors as it
>> >> looks for static libraries.
>> >>
>> >> Can this be made to respect externally setting the variable? Maybe it
>> >> should only show up if set, for example? Alternatively, do external
>> >> projects need to implement their own version of the variable, like a
>> >> CLANG_LINK_LLVM_DYLIB?
>> >>
>> >> > This is related to D44391, but that change assumed the client knew
>> >> > whether they wanted the dylib or not.
>> >> >
>> >> > Reviewers: mgorny, beanz, labath
>> >> >
>> >> > Reviewed By: mgorny
>> >> >
>> >> > Subscribers: bollu, llvm-commits
>> >> >
>> >> > Differential Revision: https://reviews.llvm.org/D49193
>> >> >
>> >> > Modified:
>> >> >     llvm/trunk/cmake/modules/LLVMConfig.cmake.in
>> >> >
>> >> > Modified: llvm/trunk/cmake/modules/LLVMConfig.cmake.in
>> >> > URL:
>> >> > http://llvm.org/viewvc/llvm-project/llvm/trunk/cmake/modules/LLVMConfig.cmake.in?rev=337366&r1=337365&r2=337366&view=diff
>> >> > ==============================================================================
>> >> >
>> >> > --- llvm/trunk/cmake/modules/LLVMConfig.cmake.in (original)
>> >> > +++ llvm/trunk/cmake/modules/LLVMConfig.cmake.in Wed Jul 18 01:53:31 2018
>> >> > @@ -13,6 +13,8 @@ set(LLVM_COMMON_DEPENDS @LLVM_COMMON_DEP
>> >> >
>> >> >  set(LLVM_AVAILABLE_LIBS @LLVM_AVAILABLE_LIBS@)
>> >> >
>> >> > +set(LLVM_LINK_LLVM_DYLIB @LLVM_LINK_LLVM_DYLIB@)
>> >> > +
>> >> >  set(LLVM_DYLIB_COMPONENTS @LLVM_DYLIB_COMPONENTS@)
>> >> >
>> >> >  set(LLVM_ALL_TARGETS @LLVM_ALL_TARGETS@)
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > llvm-commits mailing list
>> >> > llvm-commits at lists.llvm.org
>> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits