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 "yes", then what is stopping XCode users from using the CMake build system with the normal makefile generator, instead of the XCode generator? (I'm asking in the context of "what is preventing LLVM's CMake build system from replacing the autoconf build system?") --Dave.
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120628/0dd078fb/attachment.html>
Le 28 juin 2012 à 10:45, David Röthlisberger a écrit :> 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 "yes", then what is > stopping XCode users from using the CMake build system with the normal > makefile generator, instead of the XCode generator? > > (I'm asking in the context of "what is preventing LLVM's CMake build > system from replacing the autoconf build system?")My answer was about "CMake developers are aware of the inferior quality of the Xcode generator, but they say that there is little interest from the Xcode users." In the context of LLVM, I don't know if Xcode user uses cmake or autoconf. Personally I'm using autoconf because actually cmake build fails when trying to build llvm/clang/libc++, and that's what I need to do. I know Chandler is working on libc++/compiler_rt integration in cmake, so I will try again once he is done. -- Jean-Daniel
hume npx <humeafo at gmail.com> writes: Sorry for commenting the bug report here, but I can't loging to bugzilla right now.> 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,There is indeed a problem with the value assigned to LLVM_TOOLS_BINARY_DIR in LLVMConfig.cmake.in because such value is valid for an uninstalled build, but not for an installed one, because on installing, 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 and the later needs modification only for uninstalled builds, as the comment above the IF hints. Apart from that, your patch seems wrong for me because you are using CMAKE_CURRENT_LIST_DIR. Such method only gives the desired result for uninstalled, in-source builds.> I'am I bit > familiar with cmake, so if there tasks pending for absence of developer, > I'd like to join.Chandler is doing a great job at maintaining the CMake scripts, but I'm sure he will welcome any help others can offer.> cmake is not perfect but it's open, but many improvements maybe merged > upstream.[snip]