similar to: llvm-config deprecation

What is the purpose of supporting this "copy directories around" sort of build strategy anyway? At the end of the day, the way these packages get installed is via system package managers is independently, each project finding its dependencies with the standard prefix path. When I compile from source it's always like this: $ cd llvm-6.0.0rc2.src/ $ mkdir build $ cd build $ cmake ..

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

I am trying to build Clang/LLVM with -DLLVM_BUILD_LLVM_DYLIB=ON and -DLLVM_LINK_LLVM_DYLIB=ON to reduce the size of toolchain. I am getting LINK error 1181 about `lib\LLVM.lib` not found. After investigating, `lib\LLVM.lib` is supposed to be produced along with `bin\LLVM.dll`. `bin\LLVM.dll` is indeed produced, but it does not contain any exported symbols (10KB only) because LLVM does not use

On 15 Feb 2018, at 15:45, Siegmar Gross via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > today I've tried to build llvm-6.0.0rc2 using Cmake on my "SUSE Linux > Enterprise Server 12.3 (x86_64)" with the following commands (gcc-6.4.0 > is necessary for CUDA-9.0). > > > wget http://prereleases.llvm.org/6.0.0/rc2/llvm-6.0.0rc2.src.tar.xz > wget

Hi Greg, On Fri, Mar 21, 2014 at 11:18 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Hi Alexey, > > CMAKE_PREFIX_PATH is a convenient mechanism for exposing prebuilt > install directories to a CMake build. It contains a colon-separated > list of paths. Each path points to a directory that contains > directory names that are meaningful to CMake, including

Hi, today I've tried to build llvm-6.0.0rc2 using Cmake on my "SUSE Linux Enterprise Server 12.3 (x86_64)" with the following commands (gcc-6.4.0 is necessary for CUDA-9.0). wget http://prereleases.llvm.org/6.0.0/rc2/llvm-6.0.0rc2.src.tar.xz wget http://prereleases.llvm.org/6.0.0/rc2/cfe-6.0.0rc2.src.tar.xz wget

The build for the Android sanitizers is unique in that it needs to link against the Android system libraries to create a shared object and its test suites. The current solution to build ASan is to drop the compiler-rt repo into the llvm source tree and cross-compile the llvm build for Android. This is a bit awkward for few reasons: 1) Not all of llvm can be cross-compiled for Android.

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

where should the file build_llvm_package.bat be placed and how should the build_llvm_package.bat be called? or is there a another way to do a two stage build of the llvm project on windows starting with using visual studio 2017 community. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I ran CMake on the command line with this command: " cmake .. -DCMAKE_INSTALL_PREFIX=../install_x64 -T host=x64 -G "Visual Studio 15 2017 Win64" -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly " And I have LLD and Clang where they should be. But I still couldn't generate project files. The path to the build and installation directories don't have spaces at all this

Yeah, I don't think that matters. It did set the toolset architecture to x64. You know, I attached those log files for a reason. ________________________________ From: Zachary Turner <zturner at google.com> Sent: Tuesday, November 27, 2018 4:27 AM To: Osman Zakir Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Have LLD and Clang in their correct locations, but still can't

> Alexey's approach with CMake sub-projects. I prefer that direction as well, but what I've proposed is a solution that works today. To support cross-compilation, we'll need to loop over each supported arch (llvm-config --targets-built), then loop over each supported triple for each arch (hard-coded map?), and then pair up each triple with a sysroot (system paths provided by the

Hi, A few tests seem broken for a long time, some for more than a month. Would it possible for respective owners to take a look please? I'm at checkout 133a7e631cee97965e310f0d110739217427fd3d, compiling on Windows 10. These tests fail with Visual Studio 2019: Failing Tests (7): Clang Tools :: clang-tidy/checkers/cert-mem57-cpp-cpp17.cpp Clang Tools ::

Hey Guys, I'm working on a project in Android related to System-level Audio DSP Effects for Tuning Android Audio. I want to leverage Faust ( https://faust.grame.fr/) to allow users to program their own filters. Faust provides a libfaust implementation which includes a JIT Compiler which leverages LLVM and seems to be the best path for me to use. Unfortunately I'm having problems

Hi again, On Fri, Jan 15, 2016 at 11:05 AM, Ismail Donmez <ismail at i10z.com> wrote: > Hi, > > On Fri, Jan 15, 2016 at 12:59 AM, Chris Bieneman <beanz at apple.com> wrote: >> I’m kinda scared that you’re using it. What are you trying to accomplish >> that you are using it? Generally having LLVM split among that many >> dynamically loaded libraries results

Hi Timo: You need to find LLVMConfig.cmake in the binary or install directory tree, not the source tree. Although I don't embed clang/llvm, my config might help you figure it -- clang/llvm installed under (could have used build directory) ~/usr : $ cd /Users/dhinton/projects/cover/build/ && rm -rf * && CC=~/usr/bin/clang CXX=~/usr/bin/clang++ LLVM_DIR=~/usr/lib/cmake/llvm

> Note that ASan tests on Android require llvm-symbolizer binary. That's a really good point. And I see that llvm-symbolizer can't just be pulled into compiler-rt because it has dependencies on DebugInfo, Object, and Support libraries. This throws a big wrench in Alexey's plan to have the native compiler-rt build generate the cross-compiled binaries for all supported targets. We

These errors seem pretty pervasive for me on a clean build. It appears that it arises because when tablegen'd headers are included in a .h file, every place where that .h file is used needs a dependency on the corresponding IncGen targets. This seems broken in the short term and unmaintainable in the long term. There really needs to be a way of automatically generating the right

Hi, On Sun, Jan 17, 2016 at 1:04 PM, Dan Liew <dan at su-root.co.uk> wrote: > On 16 January 2016 at 20:21, Ismail Donmez <ismail at i10z.com> wrote: >> On Sat, Jan 16, 2016 at 9:33 PM, Dan Liew <dan at su-root.co.uk> wrote: >>>> I am trying to enable this on openSUSE but it seems to break >>>> standalone lldb (note that we don't ship static

Just to follow-up, I'm now encountering this as well. I'm doing this on Linux. It seems that when linking with the most-recently built clang, the unit tests are taking a while to complete. It's notably not using more than 1 thread, and if using `lld` I would have expected the linker to still be running in parallel. I'm doing this on a debug build, so that might help narrow it