aboutsummaryrefslogtreecommitdiff
path: root/clang/runtime/CMakeLists.txt
diff options
context:
space:
mode:
authorGeorge Karpenkov <ekarpenkov@apple.com>2017-10-13 22:03:09 +0000
committerGeorge Karpenkov <ekarpenkov@apple.com>2017-10-13 22:03:09 +0000
commita3cd5247b3a15038e1bde0a867b69432531f98de (patch)
treea349f874f8f3f5467076e746ba16d8692fa0e039 /clang/runtime/CMakeLists.txt
parent29d3ba7576b30a37bd19a5d40f304fc39c6ab13d (diff)
downloadllvm-project-a3cd5247b3a15038e1bde0a867b69432531f98de.tar.gz
Allow building libFuzzer in two-stage compiler-rt build
When LLVM_BUILD_EXTERNAL_COMPILER_RT option is set to true, all of projects in compiler-rt are built with a freshly-built compiler using a recursive CMake invocation. (e.g. that's how compiler-rt is used in Swift) Just now I have noticed that libFuzzer binaries were missing in such a case, and ninja fuzzer returned "no such target", while ninja asan worked just fine. To my surprise, the list of allowed targets was actually hardcoded in Clang! While the current setup is clearly suboptimal, for the lack of a better fix I'm just adding `fuzzer` to a list of `compiler-rt` targets. Differential Revision: https://reviews.llvm.org/D38904 llvm-svn: 315771
Diffstat (limited to 'clang/runtime/CMakeLists.txt')
-rw-r--r--clang/runtime/CMakeLists.txt2
1 files changed, 1 insertions, 1 deletions
diff --git a/clang/runtime/CMakeLists.txt b/clang/runtime/CMakeLists.txt
index f89cd4903fbd..acc2cb6e63f5 100644
--- a/clang/runtime/CMakeLists.txt
+++ b/clang/runtime/CMakeLists.txt
@@ -109,7 +109,7 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND EXISTS ${COMPILER_RT_SRC_ROOT}/)
USES_TERMINAL)
# Add top-level targets that build specific compiler-rt runtimes.
- set(COMPILER_RT_RUNTIMES asan builtins dfsan lsan msan profile tsan ubsan ubsan-minimal)
+ set(COMPILER_RT_RUNTIMES fuzzer asan builtins dfsan lsan msan profile tsan ubsan ubsan-minimal)
foreach(runtime ${COMPILER_RT_RUNTIMES})
get_ext_project_build_command(build_runtime_cmd ${runtime})
add_custom_target(${runtime}