llvm dev - Nov 2008 - [LLVMdev] bugs in CMake build

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é
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake_llvm_bug.patch
Type: application/octet-stream
Size: 2292 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20081114/bd1483a3/attachment.obj>

Hello Kevin.

HyperQuantum <hyperquantum at 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,

-- 
Oscar

[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

On Fri, Nov 14, 2008 at 11:56 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> HyperQuantum <hyperquantum at 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
>>> 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).
I filed a bug: http://llvm.org/bugs/show_bug.cgi?id=3072


Thanks,

Kevin André