llvm dev - Sep 2014 - [LLVMdev] Can't build against LLVM-3.5 with CMake: CMakeExports.cmake broken?

On 09/09/2014 10:12 AM, Dan Liew wrote:
> because my Linux distribution just upgraded to LLVM/Clang 3.5 and I
> noticed that trying use find_package(LLVM ...) was broken :(
AFAIK, that never worked in any version of LLVM not built by CMake before.
That's why we taught cmake/modules/Makefile to generate LLVMConfig.cmake
and LLVMExports.cmake.
> What is happening is that none of the libraries are being added into
> LLVMExports.cmake file when it is generated by ``cmake/modules/Makefile``.
[snip]
> One way to "fix" this is make sure LLVMConfigLibs is also set
when
> using --enable-shared as the attached patch does.
The patch works for me and is likely sufficient at least for a fixup
during distro packaging and perhaps also in the 3.5 release branch.

Making the shared library itself available as an imported target is
a separate problem for another day (like when the CMake build system
is taught an equivalent to --enable-shared).
> Perhaps ``cmake/modules/Makefile`` should invoke llvm-config itself?
It looks like LLVMConfigLibs was created in r112714 for local use in
Makefile.rules.  The only use outside Makefile.rules is now in
cmake/modules/Makefile.  Teaching cmake/modules/Makefile to do
a direct invocation would be fine with me.

Thanks,
-Brad

On 9 September 2014 16:20, Brad King <brad.king at kitware.com>
wrote:
> On 09/09/2014 10:12 AM, Dan Liew wrote:
>> because my Linux distribution just upgraded to LLVM/Clang 3.5 and I
>> noticed that trying use find_package(LLVM ...) was broken :(
>
> AFAIK, that never worked in any version of LLVM not built by CMake before.
> That's why we taught cmake/modules/Makefile to generate
LLVMConfig.cmake
> and LLVMExports.cmake.
They tried back porting the patches you made between the 3.4 and 3.5
releases. It didn't actually work properly though.
>> What is happening is that none of the libraries are being added into
>> LLVMExports.cmake file when it is generated by
``cmake/modules/Makefile``.
> [snip]
>> One way to "fix" this is make sure LLVMConfigLibs is also set
when
>> using --enable-shared as the attached patch does.
>
> The patch works for me and is likely sufficient at least for a fixup
> during distro packaging and perhaps also in the 3.5 release branch.
Okay. I'm not sure what the policy is on applying changes to the
release branch after LLVM has been released.

@Bill What is the policy for applying changes to a release branch
after that version of LLVM has been released?
> Making the shared library itself available as an imported target is
> a separate problem for another day (like when the CMake build system
> is taught an equivalent to --enable-shared).
Agreed. My Linux distro actually usually removes all static libraries
but they make an exception for LLVM so this should work in my case.
>> Perhaps ``cmake/modules/Makefile`` should invoke llvm-config itself?
>
> It looks like LLVMConfigLibs was created in r112714 for local use in
> Makefile.rules.  The only use outside Makefile.rules is now in
> cmake/modules/Makefile.  Teaching cmake/modules/Makefile to do
> a direct invocation would be fine with me.
Okay. Attached is a patch that does this. Does this work okay for you?

Thanks,
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleaner_fix_llvm_broken_cmake_export.patch
Type: text/x-patch
Size: 1563 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140909/ad56e681/attachment.bin>

On 09/09/2014 01:53 PM, Dan Liew wrote:
>> It looks like LLVMConfigLibs was created in r112714 for local use in
>> Makefile.rules.  The only use outside Makefile.rules is now in
>> cmake/modules/Makefile.  Teaching cmake/modules/Makefile to do
>> a direct invocation would be fine with me.
> 
> Okay. Attached is a patch that does this. Does this work okay for you?
Yes.

Thanks,
-Brad