search for: add_custom_command

This morning I did a build with Ninja, which mysteriously decided to rebuild the entire system (something about a deps stamp being corrupted). When it was done, I had a new llvm-tblgen.exe, but all the target .inc files were old. Hmm. So I touched one of the TableGen source files and did another build. Again, a new llvm-tblgen.exe but no new .inc files. I do, however, have a new .inc.d file

...450 100644 > --- a/cmake/modules/TableGen.cmake > +++ b/cmake/modules/TableGen.cmake > @@ -70,6 +70,15 @@ function(add_public_tablegen_target target) > set(LLVM_COMMON_DEPENDS ${LLVM_COMMON_DEPENDS} ${target} PARENT_SCOPE) > endfunction() > > +if(LLVM_USE_HOST_TOOLS) > + 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...

...n.cmake > index 452a728..b24197b 100644 > --- a/cmake/modules/TableGen.cmake > +++ b/cmake/modules/TableGen.cmake > @@ -70,6 +70,13 @@ function(add_public_tablegen_target target) > set(LLVM_COMMON_DEPENDS ${LLVM_COMMON_DEPENDS} ${target} PARENT_SCOPE) > endfunction() > > +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(NA...

...uilt 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 fix, or would it have some other effects I'm not aware of? -Alex > >...

...;>> +++ b/cmake/modules/TableGen.cmake >>> @@ -70,6 +70,15 @@ function(add_public_tablegen_target target) >>> set(LLVM_COMMON_DEPENDS ${LLVM_COMMON_DEPENDS} ${target} PARENT_SCOPE) >>> endfunction() >>> >>> +if(LLVM_USE_HOST_TOOLS) >>> + 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 Table...

...set(${project}_TABLEGEN_EXE ${${project}_TABLEGEN_EXE} PARENT_SCOPE) >> >> + if(NOT TARGET NATIVE_LIB_LLVMSUPPORT) Instead of doing this you could move creating this out of the macro. Then it will be executed when the file is included which should only be once. >> + 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 Table...

...sure they did not, in fact, change. Should I just touch all the .td files? At 8/11/2020 12:01 PM, Michael Kruse wrote: >Before replacing a file, tblgen checks whether its content is identical. This keeps the time stamps from being updated without any change being made. > >The command in add_custom_command is not made a file dependency. The idea is that the command's input file determines the output file's content, not the algorithm that does it. > >See <https://cmake.org/cmake/help/latest/command/add_custom_command.html#command:add_custom_command>https://cmake.org/cmake/help/la...

...ex 452a728..be6729d 100644 --- a/cmake/modules/TableGen.cmake +++ b/cmake/modules/TableGen.cmake @@ -107,9 +107,18 @@ macro(add_tablegen target project) endif() set(${project}_TABLEGEN_EXE ${${project}_TABLEGEN_EXE} PARENT_SCOPE) + if(NOT TARGET NATIVE_LIB_LLVMSUPPORT) + 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_ta...

> On May 30, 2017, at 3:52 PM, Joerg Sonnenberger <joerg at bec.de> wrote: > > On Tue, May 30, 2017 at 03:49:38PM -0700, Pete Cooper via llvm-dev wrote: >> Aw, but i had a list of issues, such as: >> - tablegen doesn’t generate .d files > > Actually, it does if asked to. Oh, thanks. Thats good to know. I don’t know if ninja uses the .d as the source of real

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:

...igs, 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): add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE} COMMAND ${CMAKE_COMMAND} --build ../.. --target ${target} --config Release DEPENDS CONFIGURE_LLVM_NATIVE ${target} WORKING_DIRECTORY ${LLVM_NATIVE_BUILD} COMMENT "Building native TableGen...") My guess is that the clang an...

...5s] Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy [ 1495s] command to set the policy and suppress this warning. [ 1495s] [ 1495s] The LOCATION property should not be read from target "TargetInfo". Use the [ 1495s] target name directly with add_custom_command, or use the generator [ 1495s] expression $<TARGET_FILE>, as appropriate. [ 1495s] [ 1495s] Call Stack (most recent call first): [ 1495s] projects/dragonegg/CMakeLists.txt:87 (add_backend_header) [ 1495s] This warning is for project developers. Use -Wno-dev to suppress it. [ 1495s] [ 1...

...1 ] > movl $16, (%esp) ## Array.tart:103:11[ > Array.tart:103:11 ] > call _malloc ## Array.tart:103:11[ > Array.tart:103:11 ] > > > -- > -- Talin > Well, I figured out why the line numbers were getting set to -1: My "add_custom_command" directive in my CMake file which was supposed to run dsymutil was silently failing: add_custom_command( OUTPUT "${EXE_FILE}.dSYM/Contents/Resources/DWARF/${EXE_FILE}" COMMAND ${DSYMUTIL} "${EXE_FILE}" MAIN_DEPENDENCY "${EXE_FILE}"...

On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > >> >> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >> >>> I recently started getting this error when I try to debug my >>> LLVM-compiled program in GDB:

On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > > On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: > >> I recently started getting this error when I try to debug my LLVM-compiled >> program in GDB: >> >> Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c >> [in module

Hi All, I've been playing [1] with the newly introduced CMake interface for using exported LLVM CMake targets (e.g. the LLVMSupport library) in CMake projects and although it works there are a few things I think we should fix before the LLVM 3.5 release. Here are the current issues I see that I'd like to discuss. Just to clarify by "Targets" I mean targets in the CMake sense

...ary command in the UseSWIG module * New generator expression $<IF:cond,true-value,false-value> CMake 3.9 (released July 18th 2017): * install(TARGETS) and install(EXPORTS) support for object libraries, which will simplify the compiler-rt build * TARGET_OBJECTS generator expression support in add_custom_command and file(GENERATE) * $<TARGET_BUNDLE_DIR:tgt> and $<TARGET_BUNDLE_CONTENT_DIR:tgt> generator expressions for Apple bundles CMake 3.10 (released November 20th 2017): * include_guard() command for proper guarding against double includes of CMake scripts * An interesting aside is that thi...

...New generator expression $<IF:cond,true-value,false-value> >> >> CMake 3.9 (released July 18th 2017): >> * install(TARGETS) and install(EXPORTS) support for object libraries, which will simplify the compiler-rt build >> * TARGET_OBJECTS generator expression support in add_custom_command and file(GENERATE) >> * $<TARGET_BUNDLE_DIR:tgt> and $<TARGET_BUNDLE_CONTENT_DIR:tgt> generator expressions for Apple bundles >> >> CMake 3.10 (released November 20th 2017): >> * include_guard() command for proper guarding against double includes of CMake scripts...

...ary command in the UseSWIG module * New generator expression $<IF:cond,true-value,false-value> CMake 3.9 (released July 18th 2017): * install(TARGETS) and install(EXPORTS) support for object libraries, which will simplify the compiler-rt build * TARGET_OBJECTS generator expression support in add_custom_command and file(GENERATE) * $<TARGET_BUNDLE_DIR:tgt> and $<TARGET_BUNDLE_CONTENT_DIR:tgt> generator expressions for Apple bundles CMake 3.10 (released November 20th 2017): * include_guard() command for proper guarding against double includes of CMake scripts * An interesting aside is that thi...

...gt;> like this I get warnings > > As suggested in the CMP0026 documentation: > > http://www.cmake.org/cmake/help/v3.0/policy/CMP0026.html > > you can use the $<TARGET_FILE:SomeTool> generator expression to > get the location in a well-defined manner. It works in > add_custom_command so that should be sufficient for your example > use case. I've taken another look at this. For the simple example project [1] I'm effectively doing this. ``` add_library(ReplaceGetGlobalID MODULE ReplaceGetGlobalID.cpp) get_property(MODULE_FILE TARGET ReplaceGetGlobalID PROPERTY LOCAT...