search for: cmake_binary_dir

...using CMake as a build system; hence, i have defined CMAKE_SYSTEM_NAME variable so to turn on CMAKE_CROSSCOMPILING flag, being used by LLVM. As far as i understand from the LLVM structure; when cross compiling, executable are generated with two versions; one goes under the target build directory ${CMAKE_BINARY_DIR} and the other goes into ${CMAKE_BINARY_DIR}/native/.... We i do that, i get all the tblgen + clang executable generated like that. however, the tools under TOOLS don't; and they aren't runnable on the host-build system. why is that? any ideas are appreciated. Thanks -- Rami Tel....

...can compile a simple program for i386. Looking into cmake file, it looks like i386 is failing this <https://github.com/llvm-mirror/compiler-rt/blob/master/cmake/config-ix.cmake#L76> test. I have checked variables for both the target, which looks fine to me: -- {CAN_TARGET_x86_64}: TRUE -- {CMAKE_BINARY_DIR}: /home/mohit/compiler-rt_build -- {SIMPLE_SOURCE}: /home/mohit/compiler-rt_build/CMakeFiles/simple.cc -- {TARGET_x86_64_CFLAGS}: -m64 -- TARGET_{arch}_OUTPUT: TARGET_x86_64_OUTPUT -- -DCMAKE_EXE_LINKER_FLAGS:STRING={argstring}:-DCMAKE_EXE_LINKER_FLAGS:STRING= -m64 -- {CAN_TARGET_i386}: FALSE --...

...dhinton/projects/cover/build/ && rm -rf * && CC=~/usr/bin/clang CXX=~/usr/bin/clang++ LLVM_DIR=~/usr/lib/cmake/llvm cmake ../CVRFI/ -GNinja $ cat ../CVRFI/CMakeLists.txt cmake_minimum_required(VERSION 2.8) set(CMAKE_EXPORT_COMPILE_COMMANDS ON) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) # Make Debug the default, pass -DCMAKE_BUILD_TYPE=Release to change this. if (NOT CMAKE_BUILD_TYPE) message ("Setting CMAKE_BUILD_TYPE = Debug") s...

...m -rf * && > CC=~/usr/bin/clang CXX=~/usr/bin/clang++ LLVM_DIR=~/usr/lib/cmake/llvm > cmake ../CVRFI/ -GNinja > > $ cat ../CVRFI/CMakeLists.txt > cmake_minimum_required(VERSION 2.8) > > set(CMAKE_EXPORT_COMPILE_COMMANDS ON) > > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > > # Make Debug the default, pass -DCMAKE_BUILD_TYPE=Release to change this. > if (NOT CMAKE_BUILD_TYPE) > message ("Setting CMAKE_BUILD_...

Hi all. I want to use llvm in my project and I want to make llvm a git submodule in my project. http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project At this in the documentation it claims to describe how to embed llvm into a project. I tried it that way but it doesn't work, because there isn't any findLLVM.cmake in the llvm/cmake/modules directory anymore (i don't

...ff --git a/cmake/platforms/Android.cmake b/cmake/platforms/Android.cmake index 72849b1..5f732ce 100644 --- a/cmake/platforms/Android.cmake +++ b/cmake/platforms/Android.cmake @@ -11,8 +11,15 @@ # make <target> SET(CMAKE_SYSTEM_NAME Linux) + +IF(NOT CMAKE_C_COMPILER) SET(CMAKE_C_COMPILER ${CMAKE_BINARY_DIR}/../bin/clang) +ENDIF() + +IF(NOT CMAKE_CXX_COMPILER) SET(CMAKE_CXX_COMPILER ${CMAKE_BINARY_DIR}/../bin/clang++) +ENDIF() + SET(ANDROID "1" CACHE STRING "ANDROID" FORCE) SET(ANDROID_COMMON_FLAGS "-target arm-linux-androideabi --sysroot=${LLVM_ANDROID_TOOLCHAIN_DIR}/sysr...

Hello, LLVM community. I've built a cross-toolchain on Windows and I'm now trying to run unit tests for the LLVM libraries. I used Ninja as a build system and MSVC as host compiler without an issue, but when I try to run 'ninja check-llvm-unit', I get the following error: llvm-lit.py: C:/Users/sergej/Developer/llvm-project/llvm\utils\lit\lit\TestingConfig.py:102: fatal: unable

...ave 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 SOURCE_DIR ${COMPILER_RT_SRC_ROOT} CMAKE_ARGS -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++ -DCMAKE_BUILD_TYPE=Release -DLLVM_CONFIG_PATH=${LLVM_RUNTIME...

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

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

Yes, that's the idea, when you -DLLVM_OPTIMIZED_TABLEGEN=ON tblgen is built in Release in addition to whatever /property:Configuration= is. 2015-05-29 10:03 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > That it’s faster is no surprise. Is the Release tblgen even built when > you build in Debug mode? Otherwise this

I need to build libLLVM (individual static libraries are fine at the moment) using mingw-w64 cross compilers, i686-w64-mingw32-gcc and (separately) x86_64-w64-mingw32-gcc. I'd like this to work from both Linux and Cygwin build environments. With autotools, this worked fine: ../configure --host=i686-w64-mingw32 and that's it (with mingw32-gcc-c++ installed on Fedora 23, also works fine on

...ool_dirs) + +lit.util.usePlatformSdkOnDarwin(config, lit_config) diff --git a/lit.site.cfg.py.in b/lit.site.cfg.py.in new file mode 100644 index 0000000..8c4481a --- /dev/null +++ b/lit.site.cfg.py.in @@ -0,0 +1,25 @@ + at LIT_SITE_CFG_IN_HEADER@ + +import lit.util + +config.test_exec_root = "@CMAKE_BINARY_DIR@" + +config.llvm_src_root = "@LLVM_SOURCE_DIR@" +config.llvm_obj_root = "@LLVM_BINARY_DIR@" +config.llvm_tools_dir = "@LLVM_TOOLS_DIR@" +config.llvm_libs_dir = "@LLVM_LIBS_DIR@" +config.llvm_shlib_dir = "@SHLIBDIR@" +config.llvm_plugin_ext = &q...

...; new file mode 100644 >> index 0000000..8c4481a >> --- /dev/null >> +++ b/lit.site.cfg.py.in <http://lit.site.cfg.py.in/> >> @@ -0,0 +1,25 @@ >> + at LIT_SITE_CFG_IN_HEADER@ >> + >> +import lit.util >> + >> +config.test_exec_root = "@CMAKE_BINARY_DIR@" >> + >> +config.llvm_src_root = "@LLVM_SOURCE_DIR@" >> +config.llvm_obj_root = "@LLVM_BINARY_DIR@" >> +config.llvm_tools_dir = "@LLVM_TOOLS_DIR@" >> +config.llvm_libs_dir = "@LLVM_LIBS_DIR@" >> +config.llvm_shlib_dir...

...t;http://lit.site.cfg.py.in/> > new file mode 100644 > index 0000000..8c4481a > --- /dev/null > +++ b/lit.site.cfg.py.in <http://lit.site.cfg.py.in/> > @@ -0,0 +1,25 @@ > + at LIT_SITE_CFG_IN_HEADER@ > + > +import lit.util > + > +config.test_exec_root = "@CMAKE_BINARY_DIR@" > + > +config.llvm_src_root = "@LLVM_SOURCE_DIR@" > +config.llvm_obj_root = "@LLVM_BINARY_DIR@" > +config.llvm_tools_dir = "@LLVM_TOOLS_DIR@" > +config.llvm_libs_dir = "@LLVM_LIBS_DIR@" > +config.llvm_shlib_dir = "@SHLIBDIR@&quot...

Hi folks, Building any LLVM project currently requires invoking CMake inside <monorepo-root>/llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn't really need or want it. It's also not great from a build hygiene perspective, as LLVM globally sets some flags

...or-0.7.4/CMakeLists.txt +--- tpm_emulator-0.7.4-orig/CMakeLists.txt 2012-09-17 13:16:27.832582475 -0400 ++++ tpm_emulator-0.7.4/CMakeLists.txt 2012-09-17 13:16:41.621654594 -0400 +@@ -63,6 +63,7 @@ + # include root directories + include_directories(${CMAKE_SOURCE_DIR}) + include_directories(${CMAKE_BINARY_DIR}) ++include_directories(../../vtpm_manager/manager) + + # add internal libraries + add_subdirectory(tpm) +diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt.orig tpm_emulator-0.7.4/CMakeLists.txt.orig +--- tpm_emulator-0.7.4-orig/CMakeLists.txt.orig 1969-12-31 19:00:00.000000000 -0500 ++++ tpm_em...

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