search for: llvm_install_prefix

...* > >Why? Please describe a case. > > >I need to do some futher experiment and to see whether I have been > wrong. > Since I touch this problem several months ago, so I did some test using the 3.2svn, the reason why uninstalled build 'cmake not work lies in set(LLVM_INSTALL_PREFIX @LLVM_INSTALL_PREFIX@) set(LLVM_INCLUDE_DIRS ${LLVM_INSTALL_PREFIX}/include) set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib) LLVM_INCLUDE_DIRS and LLVM_LIBRARY_DIRS points to the user specified or install tree location, but for uninstalled version, they are non-exist yet(because not run make ins...

...stall tree problem, not fully tested just for discussion.* * * Index: LLVMConfig.cmake.in =================================================================== --- LLVMConfig.cmake.in (revision 159425) +++ LLVMConfig.cmake.in (working copy) @@ -32,8 +32,11 @@ set(LLVM_ON_WIN32 @LLVM_ON_WIN32@) set(LLVM_INSTALL_PREFIX @LLVM_INSTALL_PREFIX@) -set(LLVM_INCLUDE_DIRS ${LLVM_INSTALL_PREFIX}/include) -set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib) + +get_filename_component(LLVM_CURRENT_LIST_DIR CMAKE_CURRENT_LIST_FILE PATH) +set(LLVM_INCLUDE_DIRS ${LLVM_CURRENT_LIST_DIR}/../../../include) +set(LLVM_LIBRARY_DIRS ${L...

...al LLVM_ETCDIR="${prefix}/etc/llvm"; diff --git a/cmake/modules/LLVMConfig.cmake.in b/cmake/modules/LLVMConfig.cmake.in index 6b202b2..15ba314 100644 --- a/cmake/modules/LLVMConfig.cmake.in +++ b/cmake/modules/LLVMConfig.cmake.in @@ -31,7 +31,8 @@ set(LLVM_ON_WIN32 @LLVM_ON_WIN32@) set(LLVM_INSTALL_PREFIX @LLVM_INSTALL_PREFIX@) set(LLVM_INCLUDE_DIRS ${LLVM_INSTALL_PREFIX}/include) -set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib) +set(LLVM_LIBDIR_SUFFIX "@LLVM_LIBDIR_SUFFIX@") +set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib${LLVM_LIBDIR_SUFFIX}) set(LLVM_DEFINITIONS "-D__STDC_LIM...

hume npx <humeafo at gmail.com> writes: > Hi, Óscar: > nice to hear some voice on this. about LLVM_TOOLS_BINARY_DIR, yes, it > made the installed version work only, if you'd like the uninstalled version > to work, it should be detected as you suggested. > > about LLVM_INSTALL_PREFIX the purpose is to make it really relocatable, > eg, when installed under /lib/llvm I just later need to move the > installation tree to /lusr/local/lib/llvm without re-run cmake and the > time-boring build/install process, and this is especially convinient on > Windows. LLVM_INSTALL_PR...

...not upated. As both build types should be usable for clients, the solution is to detect in LLVMConfig.cmake if it is being processed on an installed or uninstalled build and assign LLVM_TOOLS_BINARY_DIR accordingly. This can be done, for instance, comparing the values of CMAKE_CURRENT_LIST_FILE and LLVM_INSTALL_PREFIX, with the necessary adjustments. Ditto for LLVM_INCLUDE_DIRS and LLVM_LIB_DIRS. The other two variables your patch touches (LLVM_INSTALL_PREFIX and CMAKE_MODULE_PATH) does not need such corrections, as the former is precisely the *intended* location for an installed build and the later needs modif...

Hi, Óscar: nice to hear some voice on this. about LLVM_TOOLS_BINARY_DIR, yes, it made the installed version work only, if you'd like the uninstalled version to work, it should be detected as you suggested. about LLVM_INSTALL_PREFIX the purpose is to make it really relocatable, eg, when installed under /lib/llvm I just later need to move the installation tree to /lusr/local/lib/llvm without re-run cmake and the time-boring build/install process, and this is especially convinient on Windows. Use CMAKE_CURRENT_LIST_DIR while not...

...c/llvm"; > diff --git a/cmake/modules/LLVMConfig.cmake.in b/cmake/modules/LLVMConfig.cmake.in > index 6b202b2..15ba314 100644 > --- a/cmake/modules/LLVMConfig.cmake.in > +++ b/cmake/modules/LLVMConfig.cmake.in > @@ -31,7 +31,8 @@ set(LLVM_ON_WIN32 @LLVM_ON_WIN32@) > > set(LLVM_INSTALL_PREFIX @LLVM_INSTALL_PREFIX@) > set(LLVM_INCLUDE_DIRS ${LLVM_INSTALL_PREFIX}/include) > -set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib) > +set(LLVM_LIBDIR_SUFFIX "@LLVM_LIBDIR_SUFFIX@") > +set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib${LLVM_LIBDIR_SUFFIX}) > set(LLVM_DEFINIT...

Hi, Following on from another thread (Long-Term Support for LLVM Projects Extension to Build System) I'd like to discuss the testing of the exported LLVM CMake targets which can be used by consumers of LLVM as documented in [1]. Right now we don't test this feature **at all** and as a result it has been or is * broken in trunk * broken by those packaging LLVM * broken in the official

*hi,Óscar:* * * >LLVM_INSTALL_PREFIX is supposed to contain the value of > >CMAKE_INSTALL_PREFIX when you configured LLVM. Using it for setting > >other variables is just a convenience. > > Ok, I understood your point, so I'd like to develop another patch to make > it relocatable and respect the original me...

...cussion.* > * > * > Index: LLVMConfig.cmake.in > =================================================================== > --- LLVMConfig.cmake.in (revision 159425) > +++ LLVMConfig.cmake.in (working copy) > @@ -32,8 +32,11 @@ > set(LLVM_ON_WIN32 @LLVM_ON_WIN32@) > > set(LLVM_INSTALL_PREFIX @LLVM_INSTALL_PREFIX@) > -set(LLVM_INCLUDE_DIRS ${LLVM_INSTALL_PREFIX}/include) > -set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib) > + > +get_filename_component(LLVM_CURRENT_LIST_DIR CMAKE_CURRENT_LIST_FILE PATH) > +set(LLVM_INCLUDE_DIRS ${LLVM_CURRENT_LIST_DIR}/../../../include) &...

...a/cmake/modules/LLVMConfig.cmake.in b/cmake/modules/LLVMConfig.cmake.in > > index 6b202b2..15ba314 100644 > > --- a/cmake/modules/LLVMConfig.cmake.in > > +++ b/cmake/modules/LLVMConfig.cmake.in > > @@ -31,7 +31,8 @@ set(LLVM_ON_WIN32 @LLVM_ON_WIN32@) > > > > set(LLVM_INSTALL_PREFIX @LLVM_INSTALL_PREFIX@) > > set(LLVM_INCLUDE_DIRS ${LLVM_INSTALL_PREFIX}/include) > > -set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib) > > +set(LLVM_LIBDIR_SUFFIX "@LLVM_LIBDIR_SUFFIX@") > > +set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib${LLVM_LIBDIR_SUFFIX}) &...

...e it during out build process. I can build LLVM/Clang by adding it to our cmakelists.txt but when our code tries to use one of the headers (clang/CodeGen/ModuleBuilder.h), its not found as it doesnt exist. If I do a 'make install' in the llvm directory, then the file is generated in the LLVM_INSTALL_PREFIX directory. Is the 'make install' step necessary even though I'm compiling llvm along with my code? TIA, ashok

Using cmake should be the right thing if you'd like to support windows, but it seems that no enough effort on this build system, eg http://llvm.org/bugs/show_bug.cgi?id=12157 three months passed, I'am I bit familiar with cmake, so if there tasks pending for absence of developer, I'd like to join. cmake is not perfect but it's open, but many improvements maybe merged upstream.

...> process. I can build LLVM/Clang by adding it to our cmakelists.txt but > when our code tries to use one of the headers > (clang/CodeGen/ModuleBuilder.h), its not found as it doesnt exist. If > I do a 'make install' in the llvm directory, then the file is > generated in the LLVM_INSTALL_PREFIX directory. Is the 'make install' > step necessary even though I'm compiling llvm along with my code? If you wish to use LLVM/Clang whitout installing it, you must add both the build output header path and the source header path (in this order) to your list of include paths, like thi...

On 28 Jun 2012, at 08:58, Jean-Daniel Dupas wrote: > It's a chicken and egg problems. Xcode users don't use cmake because it > generates poor Xcode projects. So what *do* XCode users do (to build llvm/clang)? Do they somehow set up XCode to build using the autoconf build system? Do they build llvm/clang outside of XCode? If the answer to either of the last two questions is

...can build LLVM/Clang by adding it to our cmakelists.txt but >> when our code tries to use one of the headers >> (clang/CodeGen/ModuleBuilder.h), its not found as it doesnt exist. If >> I do a 'make install' in the llvm directory, then the file is >> generated in the LLVM_INSTALL_PREFIX directory. Is the 'make install' >> step necessary even though I'm compiling llvm along with my code? > > If you wish to use LLVM/Clang whitout installing it, you must add both > the build output header path and the source header path (in this order) > to your list of...