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

Dan Liew dan at su-root.co.uk
Fri Jul 18 05:51:35 PDT 2014


>> I am happy to start writing a patch for the documentation
>
> Thanks.  Please Cc me for review.

Will do.

>> # LLVM_BUILD_* values available only from LLVM build tree.
>
> Those were created to simplify building Clang locally against a
> LLVM build tree.  Clang needs the LLVM source and build trees too,
> so this gives it that information.  No information is missing from
> the install-tree interface about what is actually installed, AFAIK.
>
>> 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
>
> As suggested in the CMP0026 documentation:
>
>  http://www.cmake.org/cmake/help/v3.0/policy/CMP0026.html
>
> you can use the $<TARGET_FILE:SomeTool> generator expression to
> get the location in a well-defined manner.  It works in
> add_custom_command so that should be sufficient for your example
> use case.

I've taken another look at this. For the simple example project [1]
I'm effectively doing this.

```
add_library(ReplaceGetGlobalID MODULE ReplaceGetGlobalID.cpp)

get_property(MODULE_FILE TARGET ReplaceGetGlobalID PROPERTY LOCATION)
configure_file(run.sh.in run.sh @ONLY)
```

where run.sh is a simple shell script to demonstrate how to invoke the
built library as a plug-in to the opt tool. With this CMP0026 policy
the above produces warnings.

After reading ``cmake --help-policy CMP0026`` I tried doing this instead...

```
add_library(ReplaceGetGlobalID MODULE ReplaceGetGlobalID.cpp)

file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/run.sh INPUT
${CMAKE_CURRENT_SOURCE_DIR}/run.sh.in)
```

where run.sh.in looks like...

```
#!/bin/bash

# THIS IS A HACK - the clang target is missing, just assume its in the
same directory as the opt tool
$<TARGET_FILE_DIR:opt>/clang -emit-llvm -c simple_prog.c

# Load our "Hello pass" as a plug-in to opt and run it on the LLVM
bitcode for simple_prog
$<TARGET_FILE:opt> - load $<TARGET_FILE:ReplaceGetGlobalID> -hello
-stats simple_prog.bc > /dev/null
```

This exposes a few issues

* run.sh is supposed to have executable permissions. Previously the
``configure_file`` command just copied the permissions on
``run.sh.in``. The ``file(GENERATE ...)`` command does not do this. Is
there a way to fix this?
* The clang target is not being exported (I built clang in the usually
way by placing its source inside /path/to/llvm/source/tools/clang)

Right now it seems much easier to use ``cmake_policy(SET CMP0026
OLD)``. If I use this can I rely on the old behaviour being available
forever?

>> 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.
>
> That was an oversight.  If you want to add them, they could go in
> a variable named something like "LLVM_REQUIRED_CXX_FLAGS".  Note
> that this content will need to be populated by both build systems:
>
>  cmake/modules/CMakeLists.txt
>  cmake/modules/Makefile

Oh the joy of multiple build systems :)

Given Óscar's comments that these flags aren't always necessary
perhaps we should still expose them to clients but name it as
LLVM_USED_CXX_FLAGS , we could also export the C flags (i.e.
llvm-config --cflags) as LLVM_USED_C_FLAGS

Also should we also expose whether or not LLVM was built with
assertions? It's exposed as LLVM_BUILD_ENABLE_ASSERTIONS in the build
directory but isn't available in the installed version of LLVM. I see
no reason to hide this information. This is potentially useful
information as well because it tells the client if NDEBUG was defined
when LLVM was built. Mixing LLVM built with NDEBUG defined but then
including LLVM header files in a project with NDEBUG not defined can
lead to trouble (e.g. trying to use facilities in llvm/Support/Debug.h
causes problems).

[1] https://github.com/delcypher/srg-llvm-pass-tutorial/tree/master/usingIRBuilder

Thanks,
Dan.




More information about the llvm-dev mailing list