similar to: [LLVMdev] [PATCH][CMake] Removing LLVMLibDeps.cmake and exporting libraries for CMake clients.

On Sep 8, 2010, at 5:39 PM, Michael Spencer wrote: > While implementing the object file library I ran into some weird > linking issues. It turned out that you have to manually specify extra > library dependencies in LLVMLibDeps.cmake, along with what you already > specify in the CMakeLists.txt file for the component. > > The attached patches remove this requirement, and add

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

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

Sorry my example wasn't helpful. I did take a quick look at rust -- though I didn't download or try to build it -- and they seem to allow you to use an installed or prebuilt version in addition to building it in-tree. However, even when they build it in-tree, they build the whole thing -- see mk/llvm.mk. Good luck... On Mon, Oct 10, 2016 at 1:33 AM, Timo Janssen via llvm-dev <

I decided to start playing around with building my own programming language recently, and to use LLVM to handle the assembly-level details. I'm on Kubuntu 18.04, and I started out using LLVM 6.0 from Kubuntu's packages. I put together code for dealing with my language, then went over the Kaleidoscope tutorials (which have been extremely helpful btw!). I was able to successfully get my

I just copy the latest code in HowToUseJIT and run, but the EngineBuilder(std::move(Owner)).create() keeps return null, any idea why? Here's my CMakeList: cmake_minimum_required(VERSION 3.12) project(llvm_test) set(CMAKE_CXX_STANDARD 14) find_package(LLVM REQUIRED CONFIG) llvm_map_components_to_libnames(llvm_libs support core irreader orcjit native) add_executable(llvm_test main.cpp)

[Please CC the mailing list] Eli Gottlieb <eligottlieb at gmail.com> writes: > OK, I'm just going to paste in my CMakeLists.txt file. Like I said, > I'm building an LLVM install myself by untarring llvm, mkdir build in > the root dir of the source, cd build/, cmake .., make. > >> cmake_minimum_required (VERSION 2.6) >> project (libjllvm) >>

I found a private ErrorStr member, but didn't find the get function of this member, could you tell me how I can get the error message? On Wed, Sep 18, 2019 at 4:02 PM mayuyu.io <admin at mayuyu.io> wrote: > Isn’t there a method in EngineBuilder to get the error message or > something? > I assume it’s you didn’t link in the JIT module > > Zhang > > 在

I compiled and installed it to the prefix /usr, but that's not the issue. Once I actually compile and install LLVM with CMake by hand, I get the share/llvm/cmake stuff installed correctly (can those files be included in "normal" builds, or will LLVM switch to CMake as its primary build system?). Now I'm running into the problem of cflags or includes or something not being

Description =========== This patch adds support of CMake meta build system, so you can generate Unix makefiles, VS 6.0-2017 projects and many more. Features ======== * Win32 and Linux tested * Travis CI test added * Generates working Visual Studio 6.0-2017 solutions * Generates working Unix Makefile * Supported options (<option> - <default value>): * `ENABLE_FLOATING_POINT` - on

On Fri, May 15, 2020 at 6:53 PM Neil Nelson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Rarrum, > > Kubuntu 20.04 LTS is available. You may be able to upgrade to 19.10, and > then to 20.04 without reinstalling. It can be done on Xubuntu. A direct > upgrade to 20.04 should become available. LLVM 10 then installs from the > distribution packages. I put all this on a

I've managed to get 10.0.0 working now.. there were a couple things I had to adjust. The Kaleidoscope example had me doing this before creating the object file: llvm::InitializeAllTargetInfos(); llvm::InitializeAllTargets(); llvm::InitializeAllTargetMCs(); llvm::InitializeAllAsmParsers(); llvm::InitializeAllAsmPrinters(); It turns out I can get away with just this, since I'm not (yet)

We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which point people suggested upgrading the CMake version used by all of LLVM), so let’s try to move this forward. Our current required minimum version is CMake 3.4.3, which was released on January 25th 2016. It’s interesting to note

Hello all, One of the common patterns in CMake 3.x is the "superbuild" pattern, where the source trees of a dependencies are nested under a master project. In order for the projects to be modular (be agnostic to whether or not the dependencies are nested or not), the in-tree build process needs to generate the same targets as finding the dependencies out of tree. For example:

On Thu, Mar 26, 2020 at 11:48 PM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Mar 26, 2020 at 9:07 PM Shoaib Meenai via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which

On Fri, Jul 21, 2017 at 1:16 AM Reid Kleckner <rnk at google.com> wrote: > This is great news! Do we know who contributed the changes to cut the > extra library dependencies? > > Do you think we should remove ENABLE_OBJLIB to simplify our CMake files in > the near future? It seems to me that anyone who cares about highly parallel > build throughput can upgrade CMake to get

Assuming this is a one-time version bump, this seems reasonable to me. Perhaps this goes without saying, but the warning for point 1 should only happen if you don’t have CMake >= 3.13.4 installed. It sounded to me from your original message that you have an urgent need to upgrade to 3.8. Were you planning on going ahead with that right away? From: llvm-dev <llvm-dev-bounces at

Hi again, I'm trying to upgrade my LLVM bindings in Java from 2.9 to 3.1. To do so, I regenerated the JNI bindings from fresh LLVM 3.1 headers, and did a slight rewrite of my CMakeLists.txt file for building the C code. Problem is, cmake no longer finishes at all. I receive the following output, and then it just runs forever (while still responding to a CTRL-C): > eli at

I’m in favor of all this. Thanks for volunteering! I’m happy to help out in whatever way. Some things it might be worth figuring out for future upgrades: * If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)? * For platforms like Ubuntu

Hi Óscar, On 14 March 2010 15:06, Óscar Fuentes <ofv at wanadoo.es> wrote: > Victor Zverovich <victor.zverovich at googlemail.com> writes: > > > Hi llvm-dev, > > > > Attached are two patches for the LLVM cmake build system. > > > > The first one adds static runtimes (MT and MTd) to the list of runtimes > for > > the MSVC build. > >