tup not adding a dependancy to a header file

[skgbanga]

Hello, I have a simple directory structure which looks like this: ...folder1 ......file1.h ......file2.h

...folder2 ......main.cpp

main.cpp has #include for file1.h and file2.h Now I know that in tup rules, one doesn't have to specify file1.h and file2.h anywhere since

"tup instruments all commands that it executes in order to determine what files were actually read from (the inputs) and written to (the outputs). When the C preprocessor opens the header file, tup will notice that and automatically add the dependency"

The problem is it is not happening in my case. i.e. I edit file1.h, but 'tup upd' doesn't do anything. For some reason, tup doesn't think main.cpp has dependancy on file1.h and file2.h

Tup rule is simple enough : main.cpp |> clang++ -c %f -o %o |> %B.o

What are the possible ways in which I can debug this? (I have tried doing tup init again). Is there a way I can see the dependancy graph?

[skgbanga]

One thing I want to mention is that in a separate project this works, but not in this project. So what I am essentially looking for is "Why is this not working in this project" and trying to debug further.

Also, I had created a Tupfile in folder1 at one stage but deleted in because I no longer needed to make object files. I fear that might have messed tup's internal dependancy graph.

[gittup]

Is it possible to zip up your files and email them to me? Ideally just enough to reproduce the single command that is not picking up dependencies correctly, including the .tup folder so I can see the database. And what platform are you on?

Does the file get recompiled if you change main.cpp? And are you sure that the headers you are modifying are actually the ones that get included? (ie: maybe there's another file1.h somewhere earlier in the include path that's it is actually using).

You can try using the 'tup graph' command to show parts of the database by using graphviz. Eg:

tup graph . | dot -Tpng > graph.png

Just adding a Tupfile in a folder and removing shouldn't cause problems with the dependency graph. There are lots of tests covering adding & removing Tupfiles - that's a perfectly normal thing to do!

[skgbanga]

Hey, Thanks for getting back. I think I am no more afflicted by the same problem, though I am not sure how it got resolved itself. (maybe I was doing something wrong). In the meantime I was using "tup clean" hack

git clean -Xfd tup init tup

So the side project has got slightly big: https://github.com/skgbanga/FoodThought

There is a file called BuildGraph.png which shows the build structure. I have replaced actual build commands with 'tup' to make dot visualise it better. There is something which I don't understand in this. Look at node number 15 (lower left corner, ClientHandler.hpp). The graph shows that it has no incoming edge, where as if you look at the actual file, there are plenty of #include on top of it. Which means that tup is not adding dependancies based on preprocessor's output. [Infact, right part of graph is not interacting with left side head node at all which seems very wrong to me]

I think my understand of this is incomplete. Please feel free to close this issue.

Regards,

[gittup]

If you use the '^' markers in the command-line to shorten what is displayed, tup will use that in the graph. Eg:

: foreach *.c |> ^ CC %f^ gcc -c %f -o %o -DFOO -DBAR |> %B.o

In this case, tup will display 'CC foo.c' instead of the longer 'gcc -c foo.c ...' both while running tup and in the 'tup graph' output. So it will make it a little easier to see the graph.

Second, you can experiment with adding the --combine flag to 'tup graph', which will make tup attempt to combine "similar" nodes, resulting in a smaller graph. However, sometimes that can hide important details, so try with and without to see what looks better depending on your use-case.

Looking at the graph and the source of ClientHandler.cpp, I would expect there to be an edge from Palantir.h (node 11) pointing to the 'tup' square that ClientHandler.cpp (node 15) also points to. (Similar for other files, like StringUtils.h). So, perhaps this indicates the missing dependency issue you are reporting.

And, looking at your Tuprules.tup file I see these lines:

FOODTHOUGHT_DIR=/Users/Sandeep/Documents/projects/FoodThought/ GTEST_DIR=/Users/Sandeep/Documents/projects/googletest/googletest/ BOOST_DIR=/Users/Sandeep/Documents/projects/boost_1_60_0/

Unfortunately on OSX, tup doesn't work out of the box with full paths. (And anyway, you shouldn't put your HOME directory in the build files, since no one else could build it!). Try something like this:

if you run 'tup init' in /Users/Sandeep/Documents/projects/FoodThought, do:

FOODTHOUGHT_DIR=$(TUP_CWD) GTEST_DIR=/Users/Sandeep/Documents/projects/googletest/googletest/ BOOST_DIR=/Users/Sandeep/Documents/projects/boost_1_60_0/

But this won't properly get dependencies on googletest and boost headers. If that's something you want, run 'tup init' on level higher in /Users/Sandeep/Documents/projects, and do:

projects/Tuprules.tup: PROJECTS_DIR = $(TUP_CWD)

projects/FoodThought/Tuprules.tup: FOODTHOUGHT_DIR=$(TUP_CWD) GTEST_DIR=$(PROJECTS_DIR)/googletest/googletest/ BOOST_DIR=$(PROJECTS_DIR)/boost_1_60_0/

This should work around the dependency issue until tup is fixed, and in any case it gets your home directory out of the build files, which is something you need to do anyway!

[skgbanga]

"And anyway, you shouldn't put your HOME directory in the build files, since no one else could build it!"

I completely agree! :) This is still very much at 40% of the overall work.

Thanks for the tips! (both the caret one and running tup init one level up)