search for: add_custom_target

...om_command(OUTPUT LIB_LLVMSUPPORT > + COMMAND ${CMAKE_COMMAND} --build . --target LLVMSupport --config Release > + DEPENDS CONFIGURE_LLVM_NATIVE > + WORKING_DIRECTORY ${LLVM_NATIVE_BUILD} > + COMMENT "Building libLLVMSupport for native TableGen...") > + add_custom_target(NATIVE_LIB_LLVMSUPPORT DEPENDS LIB_LLVMSUPPORT) > +endif(LLVM_USE_HOST_TOOLS) > + > macro(add_tablegen target project) > set(${target}_OLD_LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS}) > set(LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS} TableGen) > @@ -109,7 +118,7 @@ macro(add...

...ts aren’t being included in the ALL target, which is resulting in them not being built before the install action. I think you're right. Running "make ocaml_doc" then rerunning "make install" completed the build. > > The fix for this will probably involve changing the add_custom_target command at docs/CMakeLists.txt:146 to be split out into several add_custom_command calls that have output files, and making the target depend on the output files. Adding "ALL" to that add_custom_command let a general "make && make install" build finish. Is that a viable...

...+add_custom_command(OUTPUT LIB_LLVMSUPPORT > + COMMAND ${CMAKE_COMMAND} --build . --target LLVMSupport --config Release > + DEPENDS CONFIGURE_LLVM_NATIVE > + WORKING_DIRECTORY ${LLVM_NATIVE_BUILD} > + COMMENT "Building libLLVMSupport for native TableGen...") > +add_custom_target(NATIVE_LIB_LLVMSUPPORT DEPENDS LIB_LLVMSUPPORT) > + > macro(add_tablegen target project) > set(${target}_OLD_LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS}) > set(LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS} TableGen) > @@ -109,7 +116,7 @@ macro(add_tablegen target project) > &...

...t;> + COMMAND ${CMAKE_COMMAND} --build . --target LLVMSupport --config Release >>> + DEPENDS CONFIGURE_LLVM_NATIVE >>> + WORKING_DIRECTORY ${LLVM_NATIVE_BUILD} >>> + COMMENT "Building libLLVMSupport for native TableGen...") >>> + add_custom_target(NATIVE_LIB_LLVMSUPPORT DEPENDS LIB_LLVMSUPPORT) >>> +endif(LLVM_USE_HOST_TOOLS) >>> + >>> macro(add_tablegen target project) >>> set(${target}_OLD_LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS}) >>> set(LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS} TableGen...

...+ COMMAND ${CMAKE_COMMAND} --build . --target LLVMSupport --config Release >> + DEPENDS CONFIGURE_LLVM_NATIVE >> + WORKING_DIRECTORY ${LLVM_NATIVE_BUILD} >> + COMMENT "Building libLLVMSupport for native TableGen...") >> + add_custom_target(NATIVE_LIB_LLVMSUPPORT DEPENDS LIB_LLVMSUPPORT) >> + endif(NOT TARGET NATIVE_LIB_LLVMSUPPORT) >> + >> add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE} >> COMMAND ${CMAKE_COMMAND} --build . --target ${target} --config Release >> - DEPENDS CON...

...t;) > set(check_compiler_rt "$(MAKE)" "check-all") > else() > set(check_compiler_rt ${CMAKE_COMMAND} --build . > --target check-all --config $<CONFIGURATION>) > endif() > > ExternalProject_Get_Property(compiler-rt BINARY_DIR) > add_custom_target(check-compiler-rt > COMMAND ${check_compiler_rt} > DEPENDS compiler-rt > WORKING_DIRECTORY ${BINARY_DIR} > VERBATIM > ) > > This worked, thanks! Currently I also print fatal_error message if I detect Ninja as a CMAKE_GENERATOR. -- Alexey Samsonov, MSK ---...

...ustom_command(OUTPUT LIB_LLVMSUPPORT + COMMAND ${CMAKE_COMMAND} --build . --target LLVMSupport --config Release + DEPENDS CONFIGURE_LLVM_NATIVE + WORKING_DIRECTORY ${LLVM_NATIVE_BUILD} + COMMENT "Building libLLVMSupport for native TableGen...") + add_custom_target(NATIVE_LIB_LLVMSUPPORT DEPENDS LIB_LLVMSUPPORT) + endif(NOT TARGET NATIVE_LIB_LLVMSUPPORT) + add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE} COMMAND ${CMAKE_COMMAND} --build . --target ${target} --config Release - DEPENDS CONFIGURE_LLVM_NATIVE ${target} + DEP...

...ate the workflow of our team to use this mode, and eventually make it the default. The problem is that we want top-level targets from compiler-rt build tree be visible in the llvm/clang top-level build tree. I thought this could be achieved by ugly propagation of top-level compiler-rt targets with add_custom_target() command. (like I did this for check-compiler-rt command). > I think we > should consider punting on this one and looking for a more incremental > strategy. For instance, how about starting by moving the call > 'add_llvm_external_project(compiler-rt)' from > llvm/projec...

Hi, I'm playing around with LLVM and stumbled upon this issue while while performing "make install". The build itself was successful. I'm using the latest git version. #make install -- Installing: /home/alesko/llvm-install/bin/llvm-mc -- Installing: /home/alesko/llvm-install/bin/sancov -- Installing: /home/alesko/llvm-install/bin/opt -- Installing:

Hi Brad, Thanks for investigating this. 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. However, there is a problem with Unix Makefiles as well: parallelism doesn't work when I run "make check-compiler-rt -j8" in the original build tree,

...the default. > > > > The problem is that we want top-level targets from compiler-rt build > tree be > > visible in the llvm/clang > > top-level build tree. I thought this could be achieved by ugly > propagation > > of top-level compiler-rt > > targets with add_custom_target() command. (like I did this for > > check-compiler-rt command). > > > > > >> > >> I think we > >> should consider punting on this one and looking for a more incremental > >> strategy. For instance, how about starting by moving the call > &g...

...nd on Line 2 add this > to the if statement "AND TARGET GotsanRuntimeCheck" that should fix the > issue. > Hrm - not sure which CMakeLists.txt you're referring to? In my runtimes/compiler-rt/lib/tsan/tests/CMakeLists.txt the first few lines are: include_directories(../rtl) add_custom_target(TsanUnitTests) set_target_properties(TsanUnitTests PROPERTIES FOLDER "TSan unittests") no if condition I could modify? > > -Chris > > > > > The second path also works for many (but not all) of our other runtime > library projects. I know it works for libcxx, l...

...we'd better "clobber" the compiler-rt build tree if any of the dependencies change (we need to rebuild every compiler-rt source from scratch if clang has changed). I will also try to add support for running tests in compiler-rt build tree. I think this can be achieved by smth. like: add_custom_target(check-compiler-rt COMMAND ${CMAKE_BUILD_TOOL} check-all DEPENDS compiler-rt WORKING_DIRECTORY ${COMPILER_RT_BUILD_DIR}) > -Brad > > -- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev...

Hello backend devs, Been working on a parallelization bug in the cmake configs, where parallel makefile builds of llvm with clang and native tablegen would usually break during linking in either either the clang_tblgen or llvm_tblgen targets. Looking at the cmake command that generates the tablegen makefile commands (I think) (cmake/modules/TableGen.cmake:113-117):

...VM.cmake:1195 (add_lit_target) compiler-rt/test/tsan/CMakeLists.txt:46 (add_lit_testsuite) I'm assuming there's some systemic problem with the way I'm holding this (if it's working for other people)? - Dave > > -Chris > > > include_directories(../rtl) > > add_custom_target(TsanUnitTests) > set_target_properties(TsanUnitTests PROPERTIES > FOLDER "TSan unittests") > > no if condition I could modify? > > > > -Chris > > > > > The second path also works for many (but not all) of our other runtime > library projects. I...

...> > @@ -0,0 +1,16 @@ > > +include(LLVMExternalProjectUtils) > > + > > +# Discover the projects that use CMake in the subdirectories. > > +# Note that explicit cmake invocation is required every time a new project is > > +# added or removed. > > + > > +add_custom_target(runtimes) > > + > > +file(GLOB entries *) > > +foreach(entry ${entries}) > > + if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt) > > + get_filename_component(projName ${entry} NAME) > > + llvm_ExternalProject_Add(${projName} ${entry} USE_TOOLCHA...

...VMExternalProjectUtils) >>> > + >>> > +# Discover the projects that use CMake in the subdirectories. >>> > +# Note that explicit cmake invocation is required every time a new project is >>> > +# added or removed. >>> > + >>> > +add_custom_target(runtimes) >>> > + >>> > +file(GLOB entries *) >>> > +foreach(entry ${entries}) >>> > + if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt) >>> > + get_filename_component(projName ${entry} NAME) >>> > + llvm_Exte...

Hi Brad, I have 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}

...mpiler-rt/test/tsan/CMakeLists.txt:46 (add_lit_testsuite) > > > I'm assuming there's some systemic problem with the way I'm holding this > (if it's working for other people)? > > - Dave > > > > -Chris > > > include_directories(../rtl) > > add_custom_target(TsanUnitTests) > set_target_properties(TsanUnitTests PROPERTIES > FOLDER "TSan unittests") > > no if condition I could modify? > > > > -Chris > > > > > The second path also works for many (but not all) of our other runtime > library projects. I...

Hi Neil, I'm really not sure what you're getting at. Are you objecting to the proposal to update? The LLVM community operates by having request-for-comment (RFC) discussion threads to coalesce around a plan, then just moving forward. There is no formal argument or proposal needed. We also don't really have an official policy regarding updating CMake. In your other emails on the