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

Hi,

I can't reproduce your issue on the LLVM 3.5 release branch or trunk
it. Looking at your bug report I think your install is messed up

```

CMake Error at /usr/local/Cellar/llvm/HEAD/share/llvm/cmake/LLVMExports.cmake:6
(set_property):
  set_property could not find TARGET LLVMSupport.  Perhaps it has not yet
  been created.
Call Stack (most recent call first):
  /usr/local/share/llvm/cmake/LLVMConfig.cmake:50 (include)
  CMakeLists.txt:4 (find_package)

```

 /usr/local/share/llvm/cmake/LLVMConfig.cmake seems to calling
/usr/local/Cellar/llvm/HEAD/share/llvm/cmake/LLVMExports.cmake which
doesn't make sense. I would try cleaning up your install and start
again. If you intend to working with different versions of LLVM I
don't think it's a good idea to install it anyway. You can just build
your project against the LLVM build directory and add the LLVM tools
to your PATH when you need to.

I have a simple example project that uses ``find_package(LLVM)``.

Here are the steps I followed to build (I build against the LLVM build
directory and don't bother installing it)

$ mkdir tutorial/

# Build LLVM
$ mkdir llvm/
$ cd llvm/
$ svn co http://llvm.org/svn/llvm-project/llvm/branches/release_35 src
$ mkdir build
$ cd build
$ cmake -G Ninja ../src
$ ninja
# This is just for convenience when setting LLVM_DIR later on.
$ LLVM_BUILD_ROOT="$(pwd)"

# Build simple tutorial project
$ cd ../
$ mkdir srg-llvm-pass-tutorial
$ git clone https://github.com/delcypher/srg-llvm-pass-tutorial.git src
$ mkdir build
$ cd build/
# I'm assuming your shell will example ${LLVM_BUILD_ROOT} before invoking
cmake
$ cmake -DLLVM_DIR:PATH=${LLVM_BUILD_ROOT}/share/llvm/cmake/ -G Ninja ../src
$ ninja

Hope that helps

Dan.

Hi David,

CC'ing Brad King and Eric Christopher as they'll probably be interested.

I've just managed to reproduce your issue David. I figured this out
because my Linux distribution just upgraded to LLVM/Clang 3.5 and I
noticed that trying use find_package(LLVM ...) was broken :( . They
use the Autoconf/Makefile build system (specifically because the CMake
build system doesn't support generating a single versioned shared
library) and use --enable-shared flag to configure.

What is happening is that none of the libraries are being added into
LLVMExports.cmake file when it is generated by
``cmake/modules/Makefile``. So when a CMake project tries to use
``find_package()`` it complains about the missing targets.

This is happening because the ``LLVMConfigLibs`` makefile variable is
empty when used in ``cmake/modules/Makefile``. It is normally set in
Makefile.rules . However if you build with --enable-shared this
variable doesn't get set and so LLVMExports.cmake isn't generated
correctly.

@David: Were you also compiling this way?

One way to "fix" this is make sure LLVMConfigLibs is also set when
using --enable-shared as the attached patch does. I'm not convinced
this is the right way to do it though. Perhaps
``cmake/modules/Makefile`` should invoke llvm-config itself?

This is rather annoying. I didn't catch this before because when I was
testing I never used --enable-shared.

Thoughts?

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

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 Sep 9, 2014, at 7:12 AM, Dan Liew <dan at su-root.co.uk> wrote:
> This is happening because the ``LLVMConfigLibs`` makefile variable is
> empty when used in ``cmake/modules/Makefile``. It is normally set in
> Makefile.rules . However if you build with --enable-shared this
> variable doesn't get set and so LLVMExports.cmake isn't generated
> correctly.
> 
> @David: Were you also compiling this way?
The last time, yes. I built with OS X Homebrew (http://brew.sh) and it looks
like their formulas use --enable-shared by default, although there is an option
to turn it off
(https://github.com/Homebrew/homebrew/blob/master/Library/Formula/llvm.rb). I
was trying to work on a patch to update to 3.5.0 when I ran into the problem.

I'll try --disable-shared with the Homebrew formula and see if that unblocks
me on 3.5.0. Homebrew also has an option to pull build from trunk as well, IIRC.

Perhaps we should advise the project to build with cmake if possible?

It looks like this has been pretty much solved, sorry for the delay. I forgot
that I had llvm-dev going to a dedicated mail folder.

David