On 02/06/2014 08:12 AM, Alexey Samsonov wrote:> Please note that it makes a lot of sense to built compiler-rt (and sanitizers) with just-built > Clang. In fact, even though we should support building it with another compilers (gcc, MSVC), > using just-built-Clang should be a default scenario, like it is in configure+make build.This is possible with CMake using the ExternalProject module: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:ExternalProject The add_llvm_external_project macro already in LLVM could be taught to call ExternalProject_Add instead of add_subdirectory. This could create a custom target with dependencies appropriately configured to build after Clang. The custom target would run CMake to configure the project like an outside build and then launch the build. IIUC there is a desire for Clang to be able to be built externally to LLVM rather than subsumed into its build process. The top-level CMakeLists.txt file of Clang already has code to do that, though it can be much cleaner after my patches to LLVM to provide LLVMConfig.cmake are integrated. Then it will even be possible to build Clang using CMake against a LLVM that was built and installed using configure+make. If one would like to drive compiler-rt as part of testing a Clang built outside of LLVM then the appropriate place for the ExternalProject_Add call would be inside the build of Clang. Either way, from a quick glance at the top-level CMakeLists.txt file in compiler-rt it appears to want to know a bunch of information about Clang rather than LLVM. In this case having Clang export enough info for applications to write find_package(Clang) would make sense. This is possible to do an can be implemented using techniques similar to that in my proposed LLVMConfig.cmake patch series. -Brad
Le 6 févr. 2014 à 16:20, Brad King <brad.king at kitware.com> a écrit :> On 02/06/2014 08:12 AM, Alexey Samsonov wrote: >> Please note that it makes a lot of sense to built compiler-rt (and sanitizers) with just-built >> Clang. In fact, even though we should support building it with another compilers (gcc, MSVC), >> using just-built-Clang should be a default scenario, like it is in configure+make build. > > This is possible with CMake using the ExternalProject module: > > http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:ExternalProject > > The add_llvm_external_project macro already in LLVM could be taught > to call ExternalProject_Add instead of add_subdirectory. This could > create a custom target with dependencies appropriately configured to > build after Clang. The custom target would run CMake to configure the > project like an outside build and then launch the build. > > IIUC there is a desire for Clang to be able to be built externally to > LLVM rather than subsumed into its build process. The top-level > CMakeLists.txt file of Clang already has code to do that, though it > can be much cleaner after my patches to LLVM to provide LLVMConfig.cmake > are integrated. Then it will even be possible to build Clang using > CMake against a LLVM that was built and installed using configure+make. > > If one would like to drive compiler-rt as part of testing a Clang built > outside of LLVM then the appropriate place for the ExternalProject_Add > call would be inside the build of Clang.Look like what we need to build compiler-rt. Actually the makefile responsible to launch the compiler-rt build is in clang/runtime/compiler-rt. Using ExternalProject_Add, we can probably add the CMake part beside that existing file, so everything will be at the same place.> Either way, from a quick glance at the top-level CMakeLists.txt file > in compiler-rt it appears to want to know a bunch of information about > Clang rather than LLVM. In this case having Clang export enough info > for applications to write find_package(Clang) would make sense. This > is possible to do an can be implemented using techniques similar to > that in my proposed LLVMConfig.cmake patch series. > > -Brad > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Jean-Daniel
On Thu, Feb 6, 2014 at 7:57 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote:> > Le 6 févr. 2014 à 16:20, Brad King <brad.king at kitware.com> a écrit : > > > On 02/06/2014 08:12 AM, Alexey Samsonov wrote: > >> Please note that it makes a lot of sense to built compiler-rt (and > sanitizers) with just-built > >> Clang. In fact, even though we should support building it with another > compilers (gcc, MSVC), > >> using just-built-Clang should be a default scenario, like it is in > configure+make build. > > > > This is possible with CMake using the ExternalProject module: > > > > > http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:ExternalProject > > > > The add_llvm_external_project macro already in LLVM could be taught > > to call ExternalProject_Add instead of add_subdirectory. This could > > create a custom target with dependencies appropriately configured to > > build after Clang. The custom target would run CMake to configure the > > project like an outside build and then launch the build. > > > > IIUC there is a desire for Clang to be able to be built externally to > > LLVM rather than subsumed into its build process. The top-level > > CMakeLists.txt file of Clang already has code to do that, though it > > can be much cleaner after my patches to LLVM to provide LLVMConfig.cmake > > are integrated. Then it will even be possible to build Clang using > > CMake against a LLVM that was built and installed using configure+make. > > > > If one would like to drive compiler-rt as part of testing a Clang built > > outside of LLVM then the appropriate place for the ExternalProject_Add > > call would be inside the build of Clang. > > Look like what we need to build compiler-rt. Actually the makefile > responsible to launch the compiler-rt build is in clang/runtime/compiler-rt. > Using ExternalProject_Add, we can probably add the CMake part beside that > existing file, so everything will be at the same place. >OK, I feel like I need to learn more about ExternalProject_Add magic. I have a few quick questions for people with knowledge - currently: 1) "compiler-rt"'s CMake needs to know about targets in the Clang build tree ("clang") and in LLVM build tree ("FileCheck", llvm-* command-line tools, googletest etc.), and uses common macro from LLVM's CMake modules like "configute_lit_site_cfg", "parse_arguments". 2) top-level targets from compiler-rt's CMake files are visible at the root of LLVM's build tree, so that I can run "make check-asan" or even "make clang_rt.asan-x86_64" from the root of the build tree. Will we easily retain all these capabilities if we turn compiler-rt into an external project?> > > Either way, from a quick glance at the top-level CMakeLists.txt file > > in compiler-rt it appears to want to know a bunch of information about > > Clang rather than LLVM. In this case having Clang export enough info > > for applications to write find_package(Clang) would make sense. This > > is possible to do an can be implemented using techniques similar to > > that in my proposed LLVMConfig.cmake patch series. > > > > -Brad > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- Jean-Daniel > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/372750bc/attachment.html>
Just to try and share some perspective of developers on Clang and LLVM... On Thu, Feb 6, 2014 at 7:20 AM, Brad King <brad.king at kitware.com> wrote:> IIUC there is a desire for Clang to be able to be built externally to > LLVM rather than subsumed into its build process. The top-level > CMakeLists.txt file of Clang already has code to do that, though it > can be much cleaner after my patches to LLVM to provide LLVMConfig.cmake > are integrated. >While there is a strong desire to do this by some developers, it is purely for pragmatic reasons: it makes their builds *significantly* faster because xcode doesn't load the entire project, etc. I don't believe there is *any* interest in breaking the hard version lock between LLVM and Clang. We rely on that heavily, and it's likely never going away. I think the default and expected build mode should still be a merged tree where the bits and pieces desired are checked out into an LLVM checkout, and the build system can handle whatever partial build there is provided the dependencies are in place.> Then it will even be possible to build Clang using > CMake against a LLVM that was built and installed using configure+make. >I actually doubt that this is a particularly interesting build configuration. Perhaps it is for distributions or packagers, but frankly, I expect it to bitrot immediately. I don't think any devs will realistically use it. Maybe I'm wrong though... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140210/9a216688/attachment.html>
On 02/10/2014 06:08 AM, Chandler Carruth wrote:> Just to try and share some perspective of developers on Clang and LLVM... > > On Thu, Feb 6, 2014 at 7:20 AM, Brad King <brad.king at kitware.com> wrote: > >> IIUC there is a desire for Clang to be able to be built externally to >> LLVM rather than subsumed into its build process. The top-level >> CMakeLists.txt file of Clang already has code to do that, though it >> can be much cleaner after my patches to LLVM to provide LLVMConfig.cmake >> are integrated. >> > > While there is a strong desire to do this by some developers, it is purely > for pragmatic reasons: it makes their builds *significantly* faster because > xcode doesn't load the entire project, etc. > > I don't believe there is *any* interest in breaking the hard version lock > between LLVM and Clang. We rely on that heavily, and it's likely never > going away. > > I think the default and expected build mode should still be a merged tree > where the bits and pieces desired are checked out into an LLVM checkout, > and the build system can handle whatever partial build there is provided > the dependencies are in place. > > >> Then it will even be possible to build Clang using >> CMake against a LLVM that was built and installed using configure+make. >> > > I actually doubt that this is a particularly interesting build > configuration. Perhaps it is for distributions or packagers, but frankly, I > expect it to bitrot immediately. I don't think any devs will realistically > use it. Maybe I'm wrong though...At best, we would have some buildbots using this configuration (we could switch existing onces to this scheme). I don't think we need it for clang, but many external projects would like to use cmake to build against LLVM as installed by debian e.g. In this case, it is great if even an autoconf installation of LLVM provides the relevant cmake pieces. Cheers, Tobias