search for: cmake_current_list_fil

.... In fact, it was introduced in cmake 2.8.3 while the LLVM CMake scripts require just 2.8. The solution may work indeed, but I'm always reluctant to increase the minimum required version because there are users who can't easily upgrade their CMake install. Let's see what Chandler says. CMAKE_CURRENT_LIST_FILE can be used instead (just take the directory part) but I don't know when it was introduced. In http://www.cmake.org/Wiki/CMake_Useful_Variables CMAKE_CURRENT_LIST_DIR is labeled as 2.8.3 but there is no mention to the version that introduced CMAKE_CURRENT_LIST_FILE. > CMAKE_MODULE_PATH...

...5) +++ 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 ${LLVM_CURRENT_LIST_DIR}/../../../lib) + set(LLVM_DEFINITIONS "-D__STDC_LIMIT_MACROS" "-D__STDC_CONSTANT_MACROS") # We try to include using the current setting of CMAKE_MODULE_PATH...

> > *hi,Óscar:* > * * > >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

...g, LLVM_TOOLS_BINARY_DIR is 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...

...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 meanings. > > >CMAKE_CURRENT_LIST_FILE can be used instead (just take the directory > >part) but I don't know when it was introduced. In > > CMAKE_CURRENT_LIST_FILE is introduced at least in 2.6.4, if for > compatibility reasons , get_file_component and this var can achieve the > same effect. > > >No,...

...y) > @@ -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 ${LLVM_CURRENT_LIST_DIR}/../../../lib) > + What about LLVM_TOOLS_BINARY_DIR ? Have you checked that CMAKE_CURRENT_LIST_FILE is available for CMake 2.8.0 ? > set(LLVM_DEFINITIONS &quot...

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

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

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.

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