similar to: [LLVMdev] Why does cmake use LLVMBuild.txt to specify the LLVM-libs link order?

On Thu, Oct 31, 2013 at 12:17 PM, Sebastian Pop <spop at codeaurora.org> wrote: > Is there a reason to not use the cmake add_dependencies to establish the link > order of the LLVM libs instead of using the LLVMBuild.txt info? Have you tried `target_link_libraries`? The new CMake book has an example showing one static lib depending on another (page 25): `target_link_libraries(foo

The fundamental problem here is that opt doesn’t use ExecutionEngine (because it has no need to), so trying to use ExecutionEngine (or any other bit of llvm that opt doesn’t use for that matter) in an opt plugin isn’t going to work. The solution I’d go with would be to build llvm with shared libraries (use –DBUILD_SHARED_LIBS=ON on the cmake command) then link the plugin against ExecutionEngine.

On Mon, Feb 8, 2016 at 12:45 PM, Hans Wennborg <hans at chromium.org> wrote: > Chris Bieneman is probably your best bet, and maybe also Dan Liew. > Hans, My current, and hopefully final, revision of the proposed patch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

This is useful for developer who uses multicore builder. https://cmake.org/cmake/help/v3.9/release/3.9.html#other-changes - The Ninja <https://cmake.org/cmake/help/v3.9/generator/Ninja.html#generator:Ninja> generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on

Hey: I spent sometime debugging this, it seems like editing ``llvm/tools/opt.cpp`` and move ``cl::ParseCommandLineOptions(argc, argv, "llvm .bc -> .bc modular optimizer and analysis printer\n");`` to the beginning of main() solved it for me. I'm not sure if this is a bug on LLVM side Zhang ------------------ Original ------------------ From: "Viktor Was BSc via

Hi! I'm porting my own projects to CMake (seems very cool) and I want to import LLVM as external libraries. To simplify this CMake supports an export feature that can export an LLVM.cmake file that lists all libraries of LLVM. With this I could simplify the use of LLVM in my own CMake project. For this the following cmake files of LLVM have to be extended (patches are provided at the end of

Hi ! Here is the situation. I created a pass in lib/Transforms/Obfuscation. I added a createFlattening() in IPO.h and in my code to be able to use it in PassManagerBuilder.cpp (lib/Transforms/IPO) in the method PopulateModulePassManager() so I can add my pass to standard passes. It all works if I add all my files in the lib/Transforms/IPO directory. But I want to keep them away in the

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

I've been experimenting with building various llvm variants on mac OS X. Ususally, it's a case of cloning, running cmake with Xcode as generator and loading the resulting xcodeproj. In trying to build the skeleton openrisc backend from https://github.com/asl/llvm-openrisc as described in "building a backend in 24 hours" at

Hello, I work on CMake upstream. I'd like to find out in what ways CMake upstream does not fit the needs of llvm/clang, and then fill those gaps. The recent update of the minimum version to CMake 2.8.8 is a good start. Before being able to assess what is missing, it should be ensured that the current codebase is as modern as the minimum version allows, and it needs to be cleaned up. 1)

Hi, On 2017-02-01 23:20:40 -0800, Andres Freund wrote: > > Can you give a pointer to the patch so that I can assess the rough > > complexity? If it's simple enough, I'd be happy to help get it > > reviewed and in. If it's more complicated, I probably won't have the > > time to assist. > > Patch (and a prerequisite) attached. Took me a while to get

I was a bit confused with what the difference was between the old target_link_libraries(foo bar) and the new target_link_libraries(foo INTERFACE|PRIVATE|PUBLIC bar) To try to find out, I decided to look at the generated build.ninja. The difference that shows up is far fewer order only dependencies. For example build lib/TableGen/CMakeFiles/LLVMTableGen.dir/Error.cpp.o: CXX_COMPILER

I discovered that I can hack around my particular problem by placing set_property(TARGET clang PROPERTY INTERFACE_LINK_LIBRARIES) at the end of tools/driver/CMakeLists.txt. I'd prefer to fix this properly though, of course. On 12/1/17, 4:18 PM, "llvm-dev on behalf of Shoaib Meenai via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org>

On Thu, Mar 9, 2017 at 3:00 PM Chris Bieneman <beanz at apple.com> wrote: > I'll try and reproduce later today. Is this Linux? Can you give me your > CMake command line? > Excuse the delay, been busy setting up a new machine - also an opportunity to try clean cmake setups rather than my aging configurations that have a bunch of old stuff baked in and manual variables changed,

On Thu, Mar 9, 2017 at 11:25 AM Chris Bieneman <beanz at apple.com> wrote: > On Mar 8, 2017, at 4:42 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Mar 8, 2017 at 3:23 PM Chris Bieneman <beanz at apple.com> wrote: > > On Mar 8, 2017, at 3:16 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Mar 8, 2017 at

Hi, I'm trying to build LLVM 5.0.1 with all components on ARM host. I'm not cross-compiling so everything is done natively. I use the following cmake options : cmake -G "Unix Makefiles" .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_C_FLAGS="-march=armv7-a -mcpu=cortex-a9" -DCMAKE_C_COMPILER_TARGET=arm-linux-gnueabi

Fixes: [ 0%] In file included from /home/abuild/rpmbuild/BUILD/llvm/include/llvm/IR/IntrinsicInst.h:30:0, from /home/abuild/rpmbuild/BUILD/llvm/include/llvm/InstVisitor.h:16, from /home/abuild/rpmbuild/BUILD/llvm/tools/bugpoint-passes/TestPasses.cpp:19: /home/abuild/rpmbuild/BUILD/llvm/include/llvm/IR/Intrinsics.h:41:34: fatal error: llvm/IR/Intrinsics.gen: No

Hello, this is a question, concerning cmake lists configuration. I am trying to link together two llvm passes, but they still should be as two modules. So: passA - A.so passB - B.so passB should use passA , so I sould use target_link_libraries ( and of course, I have included useAnalysis in passB) . But I can't link libraries that are build as Modules, so I tried to create two libraries at

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)