search for: llvmlibdeps

While implementing the object file library I ran into some weird linking issues. It turned out that you have to manually specify extra library dependencies in LLVMLibDeps.cmake, along with what you already specify in the CMakeLists.txt file for the component. The attached patches remove this requirement, and add real CMake package export capabilities. A CMake user wishing to use LLVM can now use something similar to this: cmake_minimum_required(VERSION 2.8) find_...

On Sep 8, 2010, at 5:39 PM, Michael Spencer wrote: > While implementing the object file library I ran into some weird > linking issues. It turned out that you have to manually specify extra > library dependencies in LLVMLibDeps.cmake, along with what you already > specify in the CMakeLists.txt file for the component. > > The attached patches remove this requirement, and add real CMake > package export capabilities. A CMake user wishing to use LLVM can now > use something similar to this: > > cmake_m...

Just wanted to note that this morning that I had to (for a complete, including examples, build): 1) Move llvm/cmake/modules/LLVMLibDeps.cmake.old out of way for svn update to work 2) Modfiy llvm/examples/Makefile to remove TracingBrainF in order for a subsequent make to work Don't know if the current repository changes will fix this, or if I'm doing something else wrong. A new checkout also had the same make issue as can b...

Garrison Venn wrote: > Just wanted to note that this morning that I had to (for a complete, including examples, build): > > 1) Move llvm/cmake/modules/LLVMLibDeps.cmake.old out of way for svn update to work > 2) Modfiy llvm/examples/Makefile to remove TracingBrainF in order for a subsequent make to work > > Don't know if the current repository changes will fix this, or if I'm doing something else wrong. > A new checkout also had the same...

...I don't see why static runtime options should be excluded as they are now. It only makes more difficult to build LLVM with a static runtime. > The second one makes it possible to use llvm_config in external projects. > > In this patch I took the liberty of changing the format of > LLVMLibDeps.cmake > > to define a single variable LLVM_LIB_DEPS instead of MSVC_LIB_DEPS_*. > > LLVM_LIB_DEPS contains the list of libraries and dependencies in the > > following form: > > > > set ( LLVM_LIB_DEPS > > * <lib-name> <dependency 1> ... <dependen...

...this information on a cmake file that is >> installed along the rest of LLVM. >> >> > I don't see what is the advantage for the user in the method you describe. > In both cases the user will get an error when using library which was not > built, right? Why not install LLVMLibDeps.cmake? LLVMLibDeps.cmake will be installed. It is useful to know which libraries are available. See tools/llc/CMakeLists.txt, for instance. It uses ${LLVM_TARGETS_TO_BUILD} for building the llc tool with support for all targets included on the LLVM build.

Hi llvm-dev, Attached are two patches for the LLVM cmake build system. The first one adds static runtimes (MT and MTd) to the list of runtimes for the MSVC build. The second one makes it possible to use llvm_config in external projects. In this patch I took the liberty of changing the format of LLVMLibDeps.cmake to define a single variable LLVM_LIB_DEPS instead of MSVC_LIB_DEPS_*. LLVM_LIB_DEPS contains the list of libraries and dependencies in the following form: set ( LLVM_LIB_DEPS * <lib-name> <dependency 1> ... <dependency n> ... ) Here '*' is used as a delimiter...

...dynamic link libraries and > static libraries? What difference does it make to the dependency graph > whether a library is "archive" or "object"? This is obsolete and never concerned to Visual Studio anyways. If you are interested on dependency info look at cmake/modules/LLVMLibDeps.cmake. It is not the prettiest thing to see, but maybe you can get something from it.

...e as easy as you put it. It was discussed here recently: From: José Fonseca Subject: [PATCH]: MSVC build enhancements Date: Sat, 6 Mar 2010 10:43:50 +0000 > The second one makes it possible to use llvm_config in external projects. > In this patch I took the liberty of changing the format of LLVMLibDeps.cmake > to define a single variable LLVM_LIB_DEPS instead of MSVC_LIB_DEPS_*. > LLVM_LIB_DEPS contains the list of libraries and dependencies in the > following form: > > set ( LLVM_LIB_DEPS > * <lib-name> <dependency 1> ... <dependency n> > ... > ) &g...

...was considered good enough or... ? [snip] Anyways, if you wish to avoid duplicating info on both Makefile and CMakeLists.txt there is a simple solution: read and parse the Makefile from the corresponding CMakeLists.txt. For instance, if you put the library dependencies on the Makefile like this: LLVMLIBDEPS := foo zoo bar obtaining that info from the CMakeLists.txt and generating the cmake library dependencies is very simple, nor even you have to put anything new on all those CMakeLists.txt, just modify one of the macros that are (indirectly) called from each CMakeLists.txt.

On Jul 26, 2010, at 9:41 AM, David Piepgrass wrote: > Based on cmake/modules/LLVMLibDeps.cmake, I produced a graphviz dot file and then manually removed components and edges until the graph was small enough to be presentable. I don’t know if I can actually use LLVM due to its humongousness, but I hope the graph will be helpful to others attempting to comprehend LLVM. PNG attached; dot...

...at is > >> installed along the rest of LLVM. > >> > >> > > I don't see what is the advantage for the user in the method you > describe. > > In both cases the user will get an error when using library which was not > > built, right? Why not install LLVMLibDeps.cmake? > > LLVMLibDeps.cmake will be installed. It is useful to know which > libraries are available. See tools/llc/CMakeLists.txt, for instance. It > uses ${LLVM_TARGETS_TO_BUILD} for building the llc tool with support for > all targets included on the LLVM build. > > ________...

...; There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a problem on this line? cmake tracks library dependencies on $LLVM_ROOT/cmake/modules/LLVMLibDeps.txt That file is automatically updated on Unix and Unix-like platforms when all LLVM targets are included on the build. This means that either you update the file manually or run the build with MSYS passing -DLLVM_TARGETS_TO_BUILD=all on the cmake command line. The manual update would consist on...

...nd > > static libraries? What difference does it make to the dependency > graph whether a library is "archive" or "object"? > This is obsolete and never concerned to Visual Studio anyways. > > If you are interested on dependency info look at > cmake/modules/LLVMLibDeps.cmake. It is not the prettiest thing to see, > but maybe you can get something from it. Well, I take it this means my manually-constructed graph is crap. Well, I decided to try using automated tools such as graphvis and something called "DepCharter" to construct a more up-to-date grap...

On Oct 27, 2011, at 11:28 PM, Óscar Fuentes wrote: > Chris Lattner <clattner at apple.com> writes: > >> There are several major problems with CMake IMO: >> >> 1. It generates really slow build systems. > > In my Linux box, last time I checked (long time ago) the cmake build was > a bit faster than the Makefiles. But this is a tricky terrain, because >

One thing that helps me understand complex software is a dependency graph. I found an LLVM dependency graph at https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_16/docs/UsingLibraries.html#dependencies but it's really messy and hard to follow. From that graph I made a cleaner graph by hand (attached)... sorry about the fax-quality scan. But I have some questions about it... -

Based on cmake/modules/LLVMLibDeps.cmake, I produced a graphviz dot file and then manually removed components and edges until the graph was small enough to be presentable. I don't know if I can actually use LLVM due to its humongousness, but I hope the graph will be helpful to others attempting to comprehend LLVM. PNG attached;...

...the involved steps for building a component. First of all, use /MDd (for debug builds) or /MD (for release builds) on the command line. The required LLVM libraries can be listed using the `llvm-config' script on Unix or MinGW. The dependencies are listed too in %LLVMSourceRoot%/cmake/modules/LLVMLibDeps.cmake bus as this is a bit inconvenient to read, here they are for you: -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMMCParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Info -lLLVMInterpreter -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOp...

...#39;s awful. > Anyways, if you wish to avoid duplicating info on both Makefile and > CMakeLists.txt there is a simple solution: read and parse the Makefile > from the corresponding CMakeLists.txt. For instance, if you put the > library dependencies on the Makefile like this: > > LLVMLIBDEPS := foo zoo bar I don't see how that is any better than what is being proposed. You're just moving the complexity from one place to the other, and blocking future improvements that will build on this. -Chris

...nyways, if you wish to avoid duplicating info on both Makefile and >> CMakeLists.txt there is a simple solution: read and parse the Makefile >> from the corresponding CMakeLists.txt. For instance, if you put the >> library dependencies on the Makefile like this: >> >> LLVMLIBDEPS := foo zoo bar > > I don't see how that is any better than what is being proposed. > You're just moving the complexity from one place to the other, What I propose requires about 20 lines in the cmake build. And what Dan proposes will require changes on the cmake build as well, I...