[LLVMdev] compiler-rt CMake build (original) (raw)

Alexey Samsonov samsonov at google.com
Fri Mar 21 03:59:12 PDT 2014

On Thu, Mar 20, 2014 at 10:12 PM, Greg Fitzgerald <garious at gmail.com> wrote:

> ExternalProjectAdd(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 experiment. On the contrary, I wanted to move LLVM_BUILD_EXTERNAL_COMPILER_RT to the bots, migrate the workflow of our team to use this mode, and eventually make it the default.

The problem is that we want top-level targets from compiler-rt build tree be visible in the llvm/clang top-level build tree. I thought this could be achieved by ugly propagation of top-level compiler-rt targets with add_custom_target() command. (like I did this for check-compiler-rt command).

I think we should consider punting on this one and looking for a more incremental strategy. For instance, how about starting by moving the call 'addllvmexternalproject(compiler-rt)' from llvm/projects/CMakesLists.txt to clang/runtime? We can tweak this macro (or a clang variant) to optionally do something like:

include(AddCompilerRt) That way if CMAKEPREFIXPATH includes a path to the compiler-rt install directory, it can import all the same build targets that would be created by addsubdirectory(compiler-rt).

Probably I don't understand how CMAKE_PREFIX_PATH works. How can top-level targets from one build tree be visible in another build tree?

If I were to use CMake's ExternalProject feature, it would be from a top-level superproject. I would use it to manage dependencies and to populate CMAKEPREFIXPATH for each dependency. CMake, Make or a package manager, it wouldn't matter which you used for this part (I've used Make for this). Ultimately, you want to end up with a top-level build that performs the following: mkdir -p llvm/out && cd llvm/out cmake .. -DCMAKEINSTALLPREFIX=ship ninja check-all install cd - mkdir -p compiler-rt/out && cd compiler-rt/out cmake .. -DCMAKEPREFIXPATH=pwd/../../llvm/out/ship -DCMAKEINSTALLPREFIX=ship ninja check-all install cd - mkdir -p clang/out && cd clang/out cmake .. -DCMAKEPREFIXPATH=pwd/../../llvm/out/ship:pwd/../../compiler-rt/out/ship -DCMAKEINSTALLPREFIX=ship ninja check-all install cd - In this scenario, the compiler-rt build creates a cmake module that clang includes. It uses that cmake module to find the compiler-rt install targets and copy them into "lib/clang/". The clang build then calls 'addsubdirectory' on the compiler-rt 'test' directory, pointing it to the just-built-clang. So the dependency tree for clang is: sanitizer-tests -> clang -> compiler-rt -> c-compiler

... But we want to build compiler-rt libraries with just-built Clang as well. This is what Makefile-based build does, and what we can benefit from.

Thoughts? Thanks, Greg

On Thu, Feb 27, 2014 at 1:19 AM, Alexey Samsonov <samsonov at google.com> wrote: > > 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 ExternalProjectAdd patch >> > so that others can experiment with it? I can add quit with a >> > fatalerror/warning if the build tree rules are generated with Ninja. >> >> Since it is conditional on LLVMBUILDEXTERNALCOMPILERRT, yes. > > > Submitted as r202367. > >> >> >> > parallelism doesn't work when I run "make check-compiler-rt -j8" >> > in the original build tree, presumably because we call >> > "cd /path/to/compiler-rt/build/tree && make check-all" there. >> >> Right. The ExternalProject module has a special case for the >> Makefile generators to make with $(MAKE) instead of "make": >> >> >> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/ExternalProject.cmake;hb=v2.8.12.2#l846 >> >> so that flags like -j propagate automatically. You could do >> that too: >> >> if(CMAKEGENERATOR MATCHES "Make") >> set(checkcompilerrt "$(MAKE)" "check-all") >> else() >> set(checkcompilerrt ${CMAKECOMMAND} --build . >> --target check-all --config $) >> endif() >> >> ExternalProjectGetProperty(compiler-rt BINARYDIR) >> addcustomtarget(check-compiler-rt >> COMMAND ${checkcompilerrt} >> DEPENDS compiler-rt >> WORKINGDIRECTORY ${BINARYDIR} >> VERBATIM >> ) >> > > This worked, thanks! Currently I also print fatalerror message if I detect > Ninja as a CMAKEGENERATOR. > > > -- > Alexey Samsonov, MSK > _> ________________________ > 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/20140321/23fafe01/attachment.html>

More information about the llvm-dev mailing list