On Tue, Nov 29, 2016 at 10:41 AM, Brian Vandenberg <[email protected]> wrote:
> A pattern I've used in our build is to always compile everything from a
> common root for the following reasons (among others):
>
> * the compiler embeds a partially qualified path into the source, making it
> easy to tell the debugger to look in one common root for all source files
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
In both cases gdb can find the source file without specifying additional paths.
> * it discourages the use of relative paths as in the following (discouraging
> this has helped with refactoring efforts):
> * -I../lib
> * #include "../lib/whatever.h"
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).
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.
> * 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. Eg with a common root:
1) [0.039s] gcc -c sub/a/atestcfile.c -o atestcfile-debug.o -g
sub/a/atestcfile.c: In function 'main':
vs. a subdirectory approach:
1) [0.047s] sub/a: gcc -c atestcfile.c -o atestcfile.o
atestcfile.c: In function 'main':
(Note the "sub/a:" prefixing the command)
The command output is cached so the display doesn't become jumbled
during parallel builds.
> * when printing error messages from code a simple printf( "%s:%d: error
> msg", __FILE__, __LINE__ ); suffices
I guess you could work around that by passing in a define with pwd like:
-DTUP_SUBDIR=\"`pwd`\"
printf("%s/%s:%d error msg", TUP_SUBDIR, __FILE__, __LINE__);
But that's pretty ugly.
> These and other "features" not mentioned all help make it easier to refactor
> various projects. The project comprises over 5,000 source files and about
> 1.5 million lines of code. If nothing else, the relative pathing for the
> debugger is a must-have.
>
> How can I get tup to build from a common root (that is, not switch
> directories to where each tupfile is)?
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.
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.
-Mike
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
