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é