[LLVMdev] Fixing LLVM's CMake interface before LLVM3.5 release

[Dan Liew]

Hi All,

I've been playing [1] with the newly introduced CMake interface for
using exported LLVM CMake targets (e.g. the LLVMSupport library) in
CMake projects and although it works there are a few things I think we
should fix before the LLVM 3.5 release.

Here are the current issues I see that I'd like to discuss.

Just to clarify by "Targets" I mean targets in the CMake sense (e.g..
an executable or a library)

1 - We currently have both the old way (i.e.
llvm_map_components_to_libraries() as in [2] ) and the new way of
using built LLVM targets in CMake projects in trunk. I think we should
at some point remove the llvm_map_components_to_libraries() stuff
because it's messy. I'm not convinced it should be done in the LLVM
3.5 release because it would probably be nicer to announce for LLVM
3.5 that the old way is deprecated and remove it in LLVM 3.6 to give
clients more time to cope with the change. Either way we need to
decide on a plan for this. Thoughts?

2. The new way of using built LLVM targets in CMake projects is not
documented. If it's not documented people will probably not use it. I
am happy to start writing a patch for the documentation but I'd like
to know our position on the old way is (i.e. are we deprecating or
removing it for LLVM 3.5?) so the documentation can be rewritten
accordingly.

3. The LLVMConfig.cmake file provides something like this...

```
# LLVM_BUILD_* values available only from LLVM build tree.
set(LLVM_BUILD_BINARY_DIR "/home/dan/dev/llvm/bin")
set(LLVM_BUILD_ENABLE_ASSERTIONS "ON")
set(LLVM_BUILD_LIBRARY_DIR "/home/dan/dev/llvm/bin/./lib")
set(LLVM_BUILD_MAIN_INCLUDE_DIR "/home/dan/dev/llvm/src/include")
set(LLVM_BUILD_MAIN_SRC_DIR "/home/dan/dev/llvm/src")
set(LLVM_BUILD_TOOLS_BINARY_DIR "/home/dan/dev/llvm/bin/./bin")
```

The comment notes that these LLVM_BUILD_* variables are only available
from the build tree (i.e. they won't be available in an installed
version of LLVM).

This seems like a very odd design decision. The build system would
know where everything is being installed so really all the
LLVM_BUILD_* variables are also known at install time and a user
probably shouldn't have to care if they building against LLVM in the
build tree or against an installed version, it should "just work".

I can imagine a legitimate use of LLVM_BUILD_TOOLS_BINARY might be if
your project needed to use some LLVM tools (.e.g opt, llvm-as) as part
of its compilation process, perhaps to build a supporting runtime for
use with a JIT for example. Again I as a developer should not need to
care if my project builds against the LLVM build tree or an installed
LLVM.

In [1] I hacked around this by reading the ``LOCATION`` property of
one of the imported targets. Unfortunately CMake 3.0 really doesn't
like this I get warnings like

```
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
```

The CMake docs seem to say that the reason for this is the LOCATION
might not be completely known at configure time. In the case of
imported targets I would disagree because the LOCATION is most
definitely known. So my hack probably isn't the best way to fix this.

@Brad - I would be interested to know your thoughts on this because
you obviously know a lot more about CMake than I do.

4. Why don't we expose any of the CXXFLAGS in the CMake interface?

To use LLVM libraries as a client at minimum ``-std=c++11 -f-no-rtti``
are needed. This information is shown by the ``llvm-config
--cxxflags`` command but why aren't we exposing this information in
LLVMConfig.cmake so clients can make use of it. For example in [1] I
had to specify these by hand.

[1] https://github.com/delcypher/srg-llvm-pass-tutorial
[2] http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project

Thanks,
Dan Liew.