bugs in CMake build

[HyperQuantum]

I am using LLVM as back end for my compiler, and until now I have used
my own CMake build system for LLVM. But now LLVM has a CMake build
system of its own, so when upgrading my LLVM version I decided to move
to the 'official' one. It's not an easy transition, the build fails. I
already found one bug: in some files the variable CMAKE_SOURCE_DIR is
used for the LLVM top-level source directory, while LLVM_MAIN_SRC_DIR
should be used instead. A small patch is attached for this.

Now I get a failure for llvm-config:

Scanning dependencies of target llvm-config.target
[ 93%] Regenerating
/home/kevin/Documents/ProgProj/hyper-llvm-new/build/compiler/llvm-2.4/tools/llvm-config/LibDeps.txt.tmp
[ 93%] Generating LibDeps.txt
Updated /home/kevin/Documents/ProgProj/hyper-llvm-new/build/compiler/llvm-2.4/tools/llvm-config/LibDeps.txt
because dependencies changed
[ 93%] Checking for cyclic dependencies between LLVM libraries.
[ 93%] Building llvm-config script.
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/lib/colorgcc/bin/gcc
-- Check for working C compiler: /usr/lib/colorgcc/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Perl: /usr/bin/perl
-- Configuring traditional style.
-- Looking for argz.h
(...)
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
-- Target triplet: i686-pc-linux-gnu
llvm-config: unknown component name: powerpc
CMake Error at cmake/modules/LLVMConfig.cmake:41 (message):
  llvm-config failed for executable llc
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/llc/CMakeLists.txt:3 (add_llvm_tool)

I'll see if I can find the cause of the problem myself, or does anyone
have a suggestion about this?

Thanks,

Kevin André

cmake_llvm_bug.patch (2.24 KB)

[_utf-8_Q_C3_93scar_F]

Hello Kevin.

HyperQuantum <hyperquantum@gmail.com> writes:

I am using LLVM as back end for my compiler, and until now I have used
my own CMake build system for LLVM. But now LLVM has a CMake build
system of its own,

Yes, and it was based on yours. cmake/config-ix.cmake still has a big
chunk taken from your implementation. Thank you!

so when upgrading my LLVM version I decided to move
to the 'official' one. It's not an easy transition, the build fails. I
already found one bug: in some files the variable CMAKE_SOURCE_DIR is
used for the LLVM top-level source directory, while LLVM_MAIN_SRC_DIR
should be used instead. A small patch is attached for this.

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.

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

Now I get a failure for llvm-config:

Scanning dependencies of target llvm-config.target
[ 93%] Regenerating
/home/kevin/Documents/ProgProj/hyper-llvm-new/build/compiler/llvm-2.4/tools/llvm-config/LibDeps.txt.tmp
[ 93%] Generating LibDeps.txt
Updated /home/kevin/Documents/ProgProj/hyper-llvm-new/build/compiler/llvm-2.4/tools/llvm-config/LibDeps.txt
because dependencies changed

[snip]

-- Check if the system is big endian - little endian
-- Target triplet: i686-pc-linux-gnu
llvm-config: unknown component name: powerpc
CMake Error at cmake/modules/LLVMConfig.cmake:41 (message):
  llvm-config failed for executable llc
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/llc/CMakeLists.txt:3 (add_llvm_tool)

I'll see if I can find the cause of the problem myself, or does anyone
have a suggestion about this?

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.

If you find more problems, please report them on
http://www.llvm.org/bugs/

Regards,

[_utf-8_Q_C3_93scar_F]

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

HyperQuantum <hyperquantum@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
Bugzilla Main Page

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,

[HyperQuantum]

HyperQuantum <hyperquantum@gmail.com> writes:

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 tried with SVN revision 59362, now without removing anything I don't
need, and I got another error message:

[ 94%] Built target llvm-config.target
compiler/llvm/tools/opt/CMakeFiles/opt.dir/build.make:44:
tools/opt/CMakeFiles/opt.dir/depend.make: No such file or directory
compiler/llvm/tools/opt/CMakeFiles/opt.dir/build.make:47:
tools/opt/CMakeFiles/opt.dir/progress.make: No such file or directory
compiler/llvm/tools/opt/CMakeFiles/opt.dir/build.make:50:
tools/opt/CMakeFiles/opt.dir/flags.make: No such file or directory
make[2]: *** No rule to make target
`tools/opt/CMakeFiles/opt.dir/flags.make'. Stop.

The same LLVM sources build fine on their own, so it must have
something to do with my setup.

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

Well, I have to thank you for this because I really wanted CMake but
didn't have the time to write and maintain a complete build system for
LLVM myself. I really appreciate what you have done.

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.

This would be really cool.

If you find more problems, please report them on
Bugzilla Main Page

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

I filed a bug: 3072 – CMake build fails with LLVM in a subdirectory

Thanks,

Kevin André