search for: externalproject

> > Replicating ExternalProject would be a lot of work... > One approach commonly used with CMake modules that change frequently upstream is for the project to keep a local copy and have a check in place to use CMake's version if new enough. For instance, in llvm's source tree: cmake/modules/ExternalProject.cmake: i...

...from https://CMake.org/download/ instead of git. Then they get the source of a known stable release. If people choose to pull random git hashes or tags, that is their decision, but since the minimum version I'm proposing is widely available I think it will be uncommon. So let's talk about ExternalProject. Is it the only way? No. There are actually several approaches that could be taken here, but let me explain why I want to do it this way. At a very basic level there are really two high-level approaches to solve the problem of building runtime libraries multiple times: (1) Do the "Darwin&qu...

Hi Brad, I have a few questions regarding ExternalProject_Add. For me it doesn't really work as expected. I add the following code to the tools/clang/runtime/CMakeLists.txt to configure compiler-rt as external project: ExternalProject_Add(compiler-rt #DEPENDS clang clang++ llvm-config PREFIX ${CMAKE_BINARY_DIR}/projects/compiler-rt SO...

On Wed, Feb 26, 2014 at 9:58 PM, Brad King <brad.king at kitware.com> wrote: > On 02/26/2014 12:43 PM, Alexey Samsonov wrote: > > Do you think it makes sense to land my ExternalProject_Add patch > > so that others can experiment with it? I can add quit with a > > fatal_error/warning if the build tree rules are generated with Ninja. > > Since it is conditional on LLVM_BUILD_EXTERNAL_COMPILER_RT, yes. > Submitted as r202367. > > > parallelism doesn&...

On Thu, Mar 20, 2014 at 10:12 PM, Greg Fitzgerald <garious at gmail.com> wrote: > > ExternalProject_Add(compiler-rt ...) > > So that was quite the experiment. Looking at > clang/runtime/CMakeLists.txt, I'm not seeing a lot of bang for buck > here, and it looks like this file is prone to bit rot. Could you please elaborate on this? In fact, I don't plan to give up on this ex...

...ers) 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...

...t match the CMake options > (LLVM_DIR, COMPILER_RT_DIR). But like before, using CMAKE_PREFIX_PATH > avoids the issue. > Thanks for the great detailed explanations. I should check if we can simplify clang - compiler-rt build systems relationship with this. > > Regarding the use of ExternalProject within Clang, I think it could > create more problems than it solves. For one, it can't be used from > within the monolithic build (unless you have a duplicate llvm build, > or point CompilerRT to a subset of the currently-building LLVM build). > Could you elaborate on this? That&...

Hi Brad, Thanks for investigating this. Do you think it makes sense to land my ExternalProject_Add patch so that others can experiment with it? I can add quit with a fatal_error/warning if the build tree rules are generated with Ninja. However, there is a problem with Unix Makefiles as well: parallelism doesn't work when I run "make check-compiler-rt -j8" in the original build...

...to err in the side of caution. > > >> I've been working to try and un-do the horrible Darwin approach we have because I think it has some serious problems, but an alternative solution would be to extend the Darwin approach to every other platform. If you do this you don't need ExternalProject, but you do need to do some really dirty hacks. If you want to understand those hacks, just look at CompilerRTDarwinUtils.cmake in compiler-rt. That is a bit of evil that I’m responsible for, and I’ll be paying down that debt for a long time to come. > > Point taken, it is horrible. (sorry)...

...oving forward was that the Ubuntu LTS release was on CMake 2.8.12.x. A few days ago Ubuntu 16.04, the new LTS, was released, and it contains CMake 3.5.1. > > I have a couple of motivations for this, the biggest of which is that I’ve hit a wall trying to overcome some limitations in the CMake ExternalProject module which I can’t get past without being on CMake 3.4 or newer. These limitations make using ExternalProject to build the LLVM test-suite and runtime libraries (compiler-rt, libcxx, etc) difficult. > > The other big motivation that I have for this is the ability to cleanup code. We have 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 af...

...g CMake to the potential set of things you need to bootstrap seems like an extremely small incremental burden compared to that of getting a modern C++ toolchain. (Although clearly they won't always both be required in the same situations.) > Now, back to Chris' point: > > Is the ExternalProject the only sane way to build compiler-rt and > libc++? Because this IS a big point. > > Will it allow a way to build Compiler-RT and libc++ for *all* > supported platforms (as in -DLLVM_TARGETS_TO_BUILD)? Would it be > possible (even if not nice) to do so with an older version of CMake...

On Mon, Feb 24, 2014 at 6:57 PM, Brad King <brad.king at kitware.com> wrote: > On 02/24/2014 09:44 AM, Alexey Samsonov wrote: > > ExternalProject_Add_Step(compiler-rt force-rebuild > > DEPENDERS build > [snip] > > doesn't work for Ninja. > > What version of CMake did you use for this test? Also 2.8.10? > Yes, 2.8.10.2 to be exact. > > > Is it a CMake bug? > > Yes, though there have been some...

...se was on CMake 2.8.12.x. A few >> days ago Ubuntu 16.04, the new LTS, was released, and it contains CMake >> 3.5.1. >> >> I have a couple of motivations for this, the biggest of which is that >> I’ve hit a wall trying to overcome some limitations in the CMake >> ExternalProject module which I can’t get past without being on CMake 3.4 or >> newer. These limitations make using ExternalProject to build the LLVM >> test-suite and runtime libraries (compiler-rt, libcxx, etc) difficult. >> >> The other big motivation that I have for this is the ability t...

...find >> > this behavior reasonable. >> > >> > I don't see a problem with the current approach - we can make "run >> sanitizer >> > test suite" command in the >> > top-level build tree depend on "build/install compiler-rt >> ExternalProject" >> > steps (see how it's done currently). >> > >> >> >> >> >> >> 2) The "clang/runtime" build calls ExternalProject once for each arch >> >> it needs of compiler-rt. So once to create x86_64 libs and once for &gt...

On 2 Feb 2014, at 17:42, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> 6) If you create a proper config file, then you can populate it with >> IMPORTED targets and use it in clang. IMPORTED targets record dependencies >> and usage requirements (when you start requiring CMake 2.8.9+ at least) >> properly. >> >>

...clang/resource/dir". I find > > this behavior reasonable. > > > > I don't see a problem with the current approach - we can make "run > sanitizer > > test suite" command in the > > top-level build tree depend on "build/install compiler-rt > ExternalProject" > > steps (see how it's done currently). > > > >> > >> > >> 2) The "clang/runtime" build calls ExternalProject once for each arch > >> it needs of compiler-rt. So once to create x86_64 libs and once for > >> i386 libs. &g...

...then change the Clang sources, and re-run "make compiler-rt", > > Clang is re-built, but compiler-rt is *not* re-configured or re-built > [snip] > > even if I modify *sources* under projects/compiler-rt > > it doesn't re-build the compiler-rt libraries. > > ExternalProject was originally designed for two purposes: > > * Build third-party dependences on which local development will > not be done > > * Manage a "superbuild" project that has no binaries of its own > but has a bunch of ExternalProject_Add calls to drive set up > of a...

...ry, and doesn't add flags like "-lasan -L/path/to/clang/resource/dir". I find this behavior reasonable. I don't see a problem with the current approach - we can make "run sanitizer test suite" command in the top-level build tree depend on "build/install compiler-rt ExternalProject" steps (see how it's done currently). > > 2) The "clang/runtime" build calls ExternalProject once for each arch > it needs of compiler-rt. So once to create x86_64 libs and once for > i386 libs. > > 3) The compiler-rt build drops the ${arch} suffix from its l...

..., > my host compiler is often gcc, but I want to build, test, and ship libc++ > with the clang I just built. > > > > The runtimes build is when you use LLVM_ENABLE_RUNTIMES. It sets up the > build of all runtimes (compiler-rt, libc++, libc++abi, libunwind, etc.) as > a CMake ExternalProject which depends on the build of clang and other > toolchain tools. In other words, if I run the following: > > > > cmake -DLLVM_ENABLE_PROJECTS=clang > -DLLVM_ENABLE_RUNTIMES='libcxx;libcxxabi' path/to/my/llvm-project/llvm > > ninja cxx > > > > The build sy...