search for: add_custom_commands

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

Alright, this version works for me. Anything else that needs to be done? -Alex > On Oct 7, 2015, at 8:15 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake > index 452a728..cb06450 100644 > --- a/cmake/modules/TableGen.cmake > +++ b/cmake/modules/TableGen.cmake > @@ -70,6 +70,15 @@

It should probably be inside an `if(LLVM_USE_HOST_TOOLS)` block. That way the extra target and command won’t get added unless needed and CMake won’t spew dev warnings. Adding a target with a nonexistent dependency makes CMake dump a bunch of developer warnings. Other than that this looks good. Does it resolve the issue for you? -Chris > On Oct 7, 2015, at 4:09 PM, Alex Wang <aw1621107 at

> On Dec 9, 2015, at 1:56 PM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Not sure, but my guess is that the ocaml documents targets 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

Looks good to me! I can commit this for you today. Thanks! -Chris > On Oct 19, 2015, at 2:40 PM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Looks like the LLVMSupport patch didn't get everything -- build failed in the > same way on libLLVMTableGen. Problem/solution looked the same as for > LLVMSupport, so just tweaked the previous patch, and

> On Oct 5, 2015, at 9:37 AM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Probably should have checked earlier... Do patches go directly to llvm-commits for review instead of getting reviewed here first? > > ccing llvm-commits too in case >> On Oct 4, 2015, at 8:20 PM, Alex Wang <aw1621107 at gmail.com> wrote: >> >> Alright, got

I'm a total newbie as far as CMake and Ninja are concerned. How do I force Ninja to build the target .inc files? I'm working on TableGen, so my changes to the executable may indeed change the output files. I want to be 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

Alright, got something thrown together. Here it is inline (also attached if that's more convenient): diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake index 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

> 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:

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):

> Run it through its phases and report any bugs you find! [ 1495s] CMake Warning (dev) at projects/dragonegg/CMakeLists.txt:34 (get_target_property): [ 1495s] Policy CMP0026 is not set: Disallow use of the LOCATION target property. [ 1495s] Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy [ 1495s] command to set the policy and suppress this warning. [

On Sat, Aug 28, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > 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

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

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

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

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

>> I am happy to start writing a patch for the documentation > > Thanks. Please Cc me for review. Will do. >> # LLVM_BUILD_* values available only from LLVM build tree. > > Those were created to simplify building Clang locally against a > LLVM build tree. Clang needs the LLVM source and build trees too, > so this gives it that information. No information is