search for: add_llvm_external_project

...OT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/openmp) AND (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind)) @@ -26,6 +27,9 @@ add_llvm_external_project(libcxx) add_llvm_external_project(libunwind) endif() + if(NOT MSVC) + add_llvm_external_project(openmp) + endif() if(NOT LLVM_BUILD_EXTERNAL_COMPILER_RT) add_llvm_external_project(compiler-rt) endif() checked into llvm trunk to complete the integration of the openmp build i...

...hould 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 bu...

..., case 2 as a cross-compile, and case 3 as a combination of cases 1 & 2. Let me walk through an example of how I think this should work. If my host is OS X and I'm building Clang to target OS X and iOS, when I configure my build directory there will be an in-tree build of Compiler-RT (via add_llvm_external_project) to generate the OS X runtime libraries, and an out-of-tree-style cross-compile generated for building the iOS runtime libraries for all supported architectures. This would all be driven via command line settings like: LLVM_COMPILER_RT_IOS_ARCHS="armv7;armv7s;arm64" LLVM_COMPILER_RT_OSX_...

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

...opagation 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 > 'add_llvm_external_project(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 CMAKE_PREFIX_PATH includes a path to the compiler-rt > install directory, it...

...arwin targeting linux). >> >> Let me walk through an example of how I think this should work. >> >> If my host is OS X and I'm building Clang to target OS X and iOS, >> when I configure my build directory there will be an in-tree build >> of Compiler-RT (via add_llvm_external_project) to generate the OS X >> runtime libraries, and an out-of-tree-style cross-compile generated >> for building the iOS runtime libraries for all supported >> architectures. This would all be driven via command line settings >> like: >> >> LLVM_COMPILER_RT_IOS_ARCHS...

...(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 > >> 'add_llvm_external_project(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 CMAKE_PREFIX_PATH includes...

...compile, and case 3 as a combination of cases 1 & 2. > > Let me walk through an example of how I think this should work. > > If my host is OS X and I'm building Clang to target OS X and iOS, when I configure my build directory there will be an in-tree build of Compiler-RT (via add_llvm_external_project) to generate the OS X runtime libraries, and an out-of-tree-style cross-compile generated for building the iOS runtime libraries for all supported architectures. This would all be driven via command line settings like: > > LLVM_COMPILER_RT_IOS_ARCHS="armv7;armv7s;arm64" > LLVM_C...

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

On 6/18/15 6:49 PM, Eric Christopher wrote: > Hi John, > > Long term we don't want to keep the burden of two build systems in > tree. CMake is turning out to be the build system we want because of > its multi-platform support, etc and as soon as the CMake system can do > everything we can do with the autoconf/makefile build I plan on > turning down the support for that

The trouble is that the sanitizer tests are not really compiler-rt tests. The original compiler-rt tests are, but not the sanitizer tests. The sanitizer tests are "compiler-rt tests via clang". The sanitizer runtime is a C++ library requiring only a C++ compiler to build it (and to *unit* test it). The ASan lit tests, however, require clang, because they are testing those C++

...clang) + if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite) + include(LLVMExternalProjectUtils) + llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite + USE_TOOLCHAIN + EXCLUDE_FROM_ALL + NO_INSTALL + ALWAYS_CLEAN) + endif() + add_llvm_external_project(debuginfo-tests projects/debuginfo-tests) endif() add_subdirectory(utils/lit) add_subdirectory(test) diff --git a/projects/CMakeLists.txt b/projects/CMakeLists.txt index 9102efbdcb4..11835fa89d2 100644 --- a/projects/CMakeLists.txt +++ b/projects/CMakeLists.txt @@ -10,6 +10,7 @@ foreach(en...

...; + include(LLVMExternalProjectUtils) >> + llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite >> + USE_TOOLCHAIN >> + EXCLUDE_FROM_ALL >> + NO_INSTALL >> + ALWAYS_CLEAN) >> + endif() >> + add_llvm_external_project(debuginfo-tests projects/debuginfo-tests) >> endif() >> add_subdirectory(utils/lit) >> add_subdirectory(test) >> diff --git a/projects/CMakeLists.txt b/projects/CMakeLists.txt >> index 9102efbdcb4..11835fa89d2 100644 >> --- a/projects/CMakeLists.txt >...

...IR}/projects/test-suite) > + include(LLVMExternalProjectUtils) > + llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite > + USE_TOOLCHAIN > + EXCLUDE_FROM_ALL > + NO_INSTALL > + ALWAYS_CLEAN) > + endif() > + add_llvm_external_project(debuginfo-tests projects/debuginfo-tests) > endif() > add_subdirectory(utils/lit) > add_subdirectory(test) > diff --git a/projects/CMakeLists.txt b/projects/CMakeLists.txt > index 9102efbdcb4..11835fa89d2 100644 > --- a/projects/CMakeLists.txt > +++ b/projects/CMakeLis...

I sorta enjoy debugging stuff like this, so if you don't mind, I'll dig into it once I get a chance -- traveling so, my access is a bit sketchy right now. I'll see if I can grab the logs and let you know if I find anything interesting. On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com> wrote: > That change was added specifically to workaround a failure