On Saturday, December 3, 2016 at 9:17:27 AM UTC-7, mar...@gmail.com wrote: > > What compiler/debugger are you using? I tried this out with gcc & gdb > (compiling with -g), and the embedded paths and source files work > whether you're compiling from a common root, or compiling each file in > the directory where it resides. For example, if I have a project at > /home/marf/proj, and compile subdir/foo.c from the top-level, I'll see > the following strings in the final binary: > > /home/marf/proj > subdir/foo.c > > And if I compile it in the subdirectory, I'll see the following strings: > > /home/marf/proj/subdir > foo.c >
Come to think of it, you're absolutely right. I was incorrect. I'm always having to use pathmap (it's like "directory" in gdb, but for dbx) when debugging released builds. > I'm a fan of using a single top-level include as well instead of > adding little local includes like this. However, I think this is > independent of whether or not you are compiling with a common root. In > both cases, doing a #include "../lib/whatever.h" compiles just fine, > so if you want to discourage that you'll probably have to do it > through social means (ie: code reviews, standards, etc). You're right, I realized about a day after posting that *#include "../lib/whatever.h"* was a BS example. The *-I../lib* example still makes sense though. > Also in both cases, you can add the top-level -I flag using > -I$(TUP_CWD) in tup. If you're using the common-root approach, add > -I$(TUP_CWD) (or just -I. ) to your single top-level Tupfile. If > you're using the one-Tupfile-per-directory approach, add -I$(TUP_CWD) > to your top-level Tuprules.tup file, and include_rules in each of the > per-directory Tupfiles. Then you can #include "subdir/lib/whatever.h" > no matter where you are in the tree. > I think I'm going to have to settle for putting in something like: git_top_dir = $(git rev-parse --show-toplevel) git_relative_path = $(git rev-parse --show-prefix) cc = |> cd $(git_top_dir) && gcc $(git_relative_path)/%f -c -o %o |> CC = |> cd $(git_top_dir) && g++ $(git_relative_path)/%f -c -o %o |> > > * warnings/errors in build logs will always have partially qualified > paths > > I agree this is a little easier with the top-level approach, though > you do get the directory displayed as part of the command header in > tup, so the information is still available even if it is a little less > accessible. > Unfortunately this is one feature I don't want to live without. I'm actively refactoring a lot of stuff and I find myself doing stuff like this quite a bit: * Find warnings with [-Wunused-variable] * Extract src file, line number, variable name * If it's either un-initialized or initialized without calling a function, just delete it * Examine the rest by hand. ... but to get that level of functionality I'm also using bash to re-direct all shell output to a logfile & enabling bash's *-x* option so I can get all commands executed along with the output of each command. > IMO it's worth experimenting with the Tupfile-per-directory approach > (or using a Tupdefault file if all your Tupfiles end up being > identical), but if your compiler/debugger don't work with that then I > think any of the other approaches suggested in this thread could work. > It could be made even simpler if we supported adding normal files to > groups (along with foreach), but that doesn't work yet. > I think I'm going to end up using multiple tupfiles & just switch directories for each compilation. I'm still unsure how to proceed on a lot of things because I don't know how to do a lot of things. For example, something that's very simple in make: cflags.gtk+-2.0 := $(shell pkg-config --cflags gtk+-2.0) libs.gtk+-2.0 := $(shell pkg-config --libs gtk+-2.0) ... I'm not sure [yet] how to get the same effect in tup (cached results from executing a given command only once). > The main downside to the common-root approach is the incremental > parsing time. For example, adding a new source file would require > re-parsing all 5000 rules with a common root, but only tens or > hundreds (depending on the size of your directory), if you use a > Tupfile-per-directory. If re-parsing all 5000 rules is fast enough for > you, then you probably won't care :). Maybe you'd run into trouble > trying to do custom compiler flags though? Adding a -D flag to a > single directory or whatever might be more difficult with the > common-root approach. Perhaps you already have a solution for that > though, or prefer not to do such things. > This was a concern for me as well, and is why I'm probably going to go with distributed even though I have to make it switch directories to compile. Thanks for your response, I really appreciate it. -brian -- -- tup-users mailing list email: tup-users@googlegroups.com unsubscribe: tup-users+unsubscr...@googlegroups.com options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to tup-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
