[LLVMdev] bugs in CMake build

[Óscar Fuentes]

[I'm cc-ing the mailing list because there are some topics here of
general interest]

HyperQuantum <hyperquantum at gmail.com> writes:

>> CMAKE_SOURCE_DIR should be the same as LLVM_MAIN_SRC_DIR. If you know an
>> scenario where this is not true, please describe it.
>
> In my case it's not true. I have put LLVM in a subdirectory of my
> project (./compiler/llvm-2.4/), so the top-level CMakeLists.txt of
> LLVM isn't the actual top-level CMake file in this case.

Good point. This is one scenario that I'm interested on. See below.

>> It is not consistent to use the two, though, so I'll apply your patch.

Done. Sadly, committed your patch a few minutes before noticing your
e-mail, so the commit message talks about consistency and not about
correctness.

BTW, svn refused to accept the é on you last name (something to do with
my setup). Sorry for not writing your name as it is :-)

>> The system still has a few places where dependencies are not rock
>> solid. The specific failure you are seeing should be fixed since a few
>> days ago. Which svn revision are you using? Please restart with a
>> pristine directory.
>
> I'm using the sources of the LLVM 2.4 release, actually.

The LLVM cmake build system was quite rough at that time. I suggested to
remove it from the 2.4 release, but the release manager said it was too
late. I expect it to be useful for Visual Studio users who do not modify
the LLVM sources. Anything else would cause trouble.

> I didn't want to risk using unstable sources, as what I'm trying to do
> seems to cause failures easily already. Would you recommend me to use
> the SVN sources instead? I use two scripts to download the SVN sources
> (svn update) and build them with CMake, and the build usually
> completes fine (but I don't run any tests).

I can guarantee a prompt response to bugs and other maintenance on the
cmake build specification, but can not guarantee the same for the LLVM
libraries :-) If you want stability, keep working with 2.4 and don't use
the cmake files that comes with it. OTOH, `make check' is the only
fundamental feature missing on the cmake build of svn HEAD.

> I tried cleaning my build directory and rebuild from scratch but it
> generated almost the same error:
>
> llvm-config: unknown component name: jit
> CMake Error at cmake/modules/LLVMConfig.cmake:41 (message):
>   llvm-config failed for executable lli
> Call Stack (most recent call first):
>   cmake/modules/LLVMConfig.cmake:5 (nix_llvm_config)
>   cmake/modules/AddLLVM.cmake:16 (llvm_config)
>   cmake/modules/AddLLVM.cmake:36 (add_llvm_executable)
>   tools/lli/CMakeLists.txt:3 (add_llvm_tool)

This doesn't surprise me. It's broken.

> This reminds me that I have disabled some of the libraries that I
> don't need for my compiler (such as ExecutionEngine and the JIT), and
> I have deleted some other directories as well (like examples,
> projects, and all of the autoconf stuff except for config.guess). So I
> will have to make some adjustments to compensate for that, or I could
> see what happens with those things added again.

One of the things I plan to do is to allow the use of
LLVM_LINK_COMPONENTS by external projects. Thus, in your project, you
could do something like:

set(LLVM_MAIN_SRC_DIR /path/to/llvm/sources)
list(APPEND CMAKE_MODULE_PATH ${LLVM_MAIN_SRC_DIR}/cmake/modules)

include(LLVMClientMacros)

LLVM_LINK_COMPONENTS(bitreader bitwriter [... other llvm components])

add_executable(your_executable etc)

link_llvm_componets(your_executable)

and the libraries needed by the components you listed would be compiled
and added to your executable.

>> If you find more problems, please report them on
>> http://www.llvm.org/bugs/
>
> Well, for issues like the patch in my previous message I could have
> done that. But what if I'm not sure if something is caused by my use
> of LLVM or not, shouldn't I ask here first then?

Right now I'm the only one giving cmake support, and I read both
llvm-dev and the llvm-bugs. The bug report has the advantage of
concentrating all the discussion, attached files, etc, on one single
point, and some helpful people assigns the bug to me when they see that
cmake is involved (you can do this too on the bug reports you create, if
you happen to have my e-mail address at hand while filling the bug
report).

Regards,

-- 
Oscar