search for: target_link_libraries

...f errors of the following form: CMake Error: install(EXPORT "ClangTargets" ...) includes target "clang" which requires target "LLVMAArch64CodeGen" that is not in the export set. The issue is that we add dependencies to executables using the legacy target_link_libraries signature, which marks the dependencies as public (i.e. they apply to both the target and any other targets linking against it, or in other words they're interface dependencies). CMake requires install(EXPORT) to also export all interface dependencies, which seems like a reasonable...

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

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 bar)` where `foo` uses symbols from `bar`. -Greg

...INK_LLVM_DYLIB) + set(llvm_libs LLVM) + else() + llvm_map_components_to_libnames(llvm_libs + ${ARG_LINK_COMPONENTS} + ${LLVM_LINK_COMPONENTS} + ) + endif() + endif() + if(CMAKE_VERSION VERSION_LESS 2.8.12) # Link libs w/o keywords, assuming PUBLIC. target_link_libraries(${name} @@ -885,11 +891,18 @@ add_llvm_executable(${test_name} IGNORE_EXTERNALIZE_DEBUGINFO ${ARGN}) set(outdir ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}) set_output_directory(${test_name} BINARY_DIR ${outdir} LIBRARY_DIR ${outdir}) + if (LLVM_LINK_LLVM_DYLIB) + target_link_libra...

Hi, I've been working on a set of patches to statically link polly in the LLVM tools. There remains an error I can't seem to solve when linking llvm-lto (all other tools luckily get linked correctly): it insists adding libLLVMipo.a after libLLVMPolly.a on the link command, resulting in an error of the form: PassManagerBuilder.cpp:(.text+0x499): undefined reference to

...RY_DIR}/include/speex> + PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> + PUBLIC $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>) +if(USE_GPL_FFTW3) + target_include_directories(speex + PRIVATE $<BUILD_INTERFACE:${FFTW_INCLUDE_DIRS}>) + if(BUILD_SHARED_LIBS) + target_link_libraries(speex PRIVATE ${FFTW_LIBRARIES}) + else() + target_link_libraries(speex PUBLIC ${FFTW_LIBRARIES}) + endif() +endif() +if(HAVE_LIBM) + if(BUILD_SHARED_LIBS) + target_link_libraries(speex PRIVATE ${LIBM}) + else() + target_link_libraries(speex PUBLIC ${LIBM}) + endif() +endif() +target_compile_opt...

...+ if (DEFINED link_components AND DEFINED LLVM_DYLIB_COMPONENTS) + if("${LLVM_DYLIB_COMPONENTS}" STREQUAL "all") + set(link_components "") + else() + list(REMOVE_ITEM link_components ${LLVM_DYLIB_COMPONENTS}) + endif() + endif() target_link_libraries(${executable} LLVM) endif() However the avoiding the accidental linkage of libLLVMSupport with libLLVM and libgtest for the unittests was really tricky as two different mechanisms to pass LLVMSupport are in play. The underlying problem was that the python based llvm-build tool was forcing a de...

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 once ; A.a(static) and A.so (llvm does not allow to create shared libraries). Still that does not work : .a library has always conflicted declarat...

..._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) target_include_directories(llvm_test PUBLIC ${LLVM_INCLUDE_DIRS}) target_compile_definitions(llvm_test PUBLIC ${LLVM_DEFINITIONS}) target_link_libraries(llvm_test ${llvm_libs}) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190918/268ef7c0/attachment.html>

...ove this requirement, and add real CMake package export capabilities. A CMake user wishing to use LLVM can now use something similar to this: cmake_minimum_required(VERSION 2.8) find_package(LLVM REQUIRED) add_definitions(${LLVM_CXXFLAGS}) add_executable(llvm-external-test llvm-external-test.cpp) target_link_libraries(llvm-external-test ${LLVM_SYSTEM_LIBS} ${LLVM_JIT_LIBS} ${LLVM_NATIVECODEGEN_LIBS}) llvm+clang compile with these changes on both Linux and MSVS. Currently both patches must be applied at the same time. I can refactor them into a 3 step process if needed. Does this break anything for anyone? - M...

...ge(LLVM REQUIRED CONFIG) > llvm_map_components_to_libnames(llvm_libs support core irreader orcjit native) > > add_executable(llvm_test main.cpp) > target_include_directories(llvm_test PUBLIC ${LLVM_INCLUDE_DIRS}) > target_compile_definitions(llvm_test PUBLIC ${LLVM_DEFINITIONS}) > target_link_libraries(llvm_test ${llvm_libs}) > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL:...

...CKS_ENFORCING=OFF. - So now I am trying to rebuild LLVM, and ran into a few new problems. First, I discovered that I need the Z3 theorem prover. Unsure why this problem did not show up before. Second, I'm running into many errors like this: CMake Error at cmake/modules/AddLLVM.cmake:570 (target_link_libraries): Attempt to add link library "clangAST" to target "clangApplyReplacements" which is not built in this directory. Call Stack (most recent call first): tools/clang/cmake/modules/AddClang.cmake:86 (llvm_add_library) tools/extra/clang-apply-replacements/...

...conservative they are about compiler requirements CMake 3.11 (released March 28th 2018): * add_library() and add_executable() can be called without sources as long as target_sources() is used later * target_compile_{definitions,features,options}, target_include_directories(), target_sources(), and target_link_libraries() can set the corresponding INTERFACE_* properties on imported targets * COMPILE_DEFINITIONS supports generator expressions * COMPILE_OPTIONS source file property added * INCLUDE_DIRECTORIES source file property added * Interface libraries support custom properites CMake 3.12 (released July 17th 2...

...hared libs. See also; http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux Regardless of BUILD_SHARED_LIBS, compile units in add_executable() don't wait for preceding libraries, but targets by add_dependencies(). It doesn't break anything in llvm tree. Assume; add_executable(foo foo.cpp) target_link_libraries(foo LLVMCore) # depends on intrinsics_gen Compiling foo.cpp doesn't wait for LLVMCore, but intrinsics_gen. Linking foo waits for LLVMCore. I have been working for cutting dependencies to increase parallelism. For example, I introduced ENABLE_OBJLIB. See also, https://reviews.llvm.org/rL305635...

On 17 September 2014 16:34, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > I'll have another look tomorrow. Thanks. > IMO, it is unnecessary clutter. It will fail if ${ZLIB_LIBRARIES} or ${ZLIB_INCLUDE_DIRS} are used anyways as they will be set to NOTFOUND. Or we go back to a silent-fail solution: Fair enough. I've never

...e wrapped command etc. Wrappers are not good API proxies. Additionally, you put people who know cmake already at a disadvantage because you make the code look like 'not cmake code' by using llvm_add_library instead of add_library, the cmake command. Making that wrapper macro also invoke target_link_libraries looks odd to someone familiar with cmake. I don't fully know what this wrapper is needed for, but I looked at it a bit. if(ARG_MODULE) set_property(TARGET ${name} PROPERTY SUFFIX ${LLVM_PLUGIN_EXT}) endif() if(ARG_SHARED) if (MSVC) set_target_properties(${name}...

...ently: LLVMDebugInfo, LLVMSupport) from sanitizer runtime. 1) I can simply include LLVM headers in sanitizer runtime, and it compiles and builds static asan runtime perfectly (wow). 2) Now building and running ASan unittests is simple - you just have to add a couple of lines to CMakeLists. target_link_libraries(${testname} LLVMSupport) target_link_libraries(${testname} LLVMDebugInfo) 3) Now to make "-faddress-sanitizier" work you have to patch a Clang driver, so that it links not only ASan runtime, but also two of the mentioned static LLVM libraries (and add -lstdc++ flag as well). Bu...

...not found. -- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT -- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT - Success -- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG -- Performing Test HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG - Success CMake Warning (dev) at test/CMakeLists.txt:8 (TARGET_LINK_LIBRARIES): Cannot specify link libraries for target "CompilerRT" which is not built by this project. CMake does not support this but it used to work accidentally and is being allowed for compatibility. Policy CMP0016 is not set: target_link_libraries() reports error if only argument...

...r requirements >> >> CMake 3.11 (released March 28th 2018): >> * add_library() and add_executable() can be called without sources as long as target_sources() is used later >> * target_compile_{definitions,features,options}, target_include_directories(), target_sources(), and target_link_libraries() can set the corresponding INTERFACE_* properties on imported targets >> * COMPILE_DEFINITIONS supports generator expressions >> * COMPILE_OPTIONS source file property added >> * INCLUDE_DIRECTORIES source file property added >> * Interface libraries support custom properit...

...t(opus-example VERSION 0.0.1 LANGUAGES CXX) option(USE_SYSTEM_OPUS "Use the system opus" OFF) if (USE_SYSTEM_OPUS) find_package(Opus REQUIRED) else () add_subdirectory(${PROJECT_SOURCE_DIR}/dependencies/opus) endif() add_executable(example ${PROJECT_SOURCE_DIR}/src/example.cpp) target_link_libraries(example PRIVATE Opus::opus) Using find_package to find Opus will create the Opus::opus target, but adding the source code directly only adds opus. Aliasing opus to Opus::opus lets you keep the target_link_libraries line the same regardless of the source of the dependency. Pull request: https://git...