llvm dev - Jul 2014 - [LLVMdev] Fixing LLVM's CMake interface before LLVM3.5 release

>> 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.

On 07/18/2014 08:51 AM, Dan Liew wrote:
> * 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 file(GENERATE) command needs to be taught options to set permissions.
I've made a note for that.

For now can't you just run the script through a shell:

 /usr/bin/env bash /path/to/run.sh $args

?
> * 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)
Actually I don't think any Clang targets are exported yet.  That
may or may not belong as a separate find_package(Clang).  Not sure.
> 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?
One day the OLD behaviors may be removed.  Never set policies to OLD
except as warning fixups on existing release maintenance branches.

Since "clang" isn't exported you have to pick another target to
get the LOCATION from anyway, which is the same hack as you're
doing in the $<TARGET_FILE_DIR:opt>/clang example.

One could export a LLVM_TOOLS_DIR value from both the build and
install trees to resolve this case the old fashioned way.
> 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.
We already have a few LLVM_ENABLE_<SOMETHING> values exported.
One could add LLVM_ENABLE_ASSERTIONS.

Thanks,
-Brad

On 18 July 2014 14:38, Brad King <brad.king at kitware.com>
wrote:
> On 07/18/2014 08:51 AM, Dan Liew wrote:
>> * 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 file(GENERATE) command needs to be taught options to set permissions.
> I've made a note for that.
Ok thanks.
> For now can't you just run the script through a shell:
>
>  /usr/bin/env bash /path/to/run.sh $args
I could. The small project I have is just a small tutorial though so I
prefer ease of use for anyone using it. So for now I'll just use
``cmake_policy(SET CMP0026 OLD)``, even though as you say it is the
wrong thing to do.

>> * 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)
>
> Actually I don't think any Clang targets are exported yet.  That
> may or may not belong as a separate find_package(Clang).  Not sure.
I believe Clang has quite a few libraries of its own that are useful
so I think there should be a separate find_package(Clang).
> One could export a LLVM_TOOLS_DIR value from both the build and
> install trees to resolve this case the old fashioned way.
If I find time I'll write a patch to add this. Even though a client
can read the directory from one of the exported targets they might not
be aware they could do this so providing a LLVM_TOOLS_DIR variable
could be useful.

Would you mind if I implemented this by having code in
LLVMConfig.cmake that actually reads the $<TARGET_FILE_DIR:opt>
variable to set LLVM_TOOLS_DIR? I can guard this with a check for the
existence of the target so that if LLVM_BUILD_TOOLS is disabled an
error isn't produced.
>> 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.
>
> We already have a few LLVM_ENABLE_<SOMETHING> values exported.
> One could add LLVM_ENABLE_ASSERTIONS.
Okay. I've written a patch [1] for this. Please take a look when you the
time.



[1]
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140714/226548.html

Thanks,
Dan.