Thanks, that's useful. I now recall reading that in the documentation and not realizing how necessary that feature would be, so I forgot about it. I've confirmed it helps with gdb problem. The slowdown is not yet significant for me, so I'm content with this workaround.
I was hoping that feature would help me with another problem I just encountered, but it doesn't seem to. I am implementing a directory iterator and would like to have unit tests that run on a test directory checked into the source tree. When my unit tests run within tup, the iterator seems to make two passes over the directory: $ tup ... [ RUN ] DirectoryIterator.OurSourceTree testdir/a/ testdir/a/a.txt testdir/b/ testdir/b/b.txt testdir/a/ testdir/a/a.txt testdir/b/ testdir/b/b.txt [ OK ] DirectoryIterator.OurSourceTree (0 ms) But if I run the test executable directly, only one pass is made: $ ~/dev/build-default/..../test_DirectoryIterator ... [ RUN ] DirectoryIterator.OurSourceTree testdir/a/ testdir/a/a.txt testdir/b/ testdir/b/b.txt [ OK ] DirectoryIterator.OurSourceTree (0 ms) The macro I am using to run tests now is this: !test = |> ^c Running test %f^ ./%f && touch %o |> Is there any way to make my unit test see each file only once? Jim On Wednesday, April 2, 2014 4:00:04 PM UTC-7, Pat Pannuto wrote: > > Yes. It's a bit hidden in the documentation, but the relevant bit is here: > > *^-flags* In a command string that uses the ^ TEXT^ sequence, flag > characters can be placed immediately after the ^ until the first space > character or closing carat. For example: > > : foo.c |> ^c CC %f^ gcc --coverage %f -o %o |> foo | foo.gcno > : bar.c |> ^c^ gcc --coverage %f -o %o |> bar | bar.gcno > > > In the foo.c case, the command is run in a chroot and will display "CC > foo.c". In the bar.c case, the command is run in a chroot and the "gcc > --coverage bar.c -o bar" string is displayed. These are the supported flag > characters: > *c* The 'c' flag causes the command to run inside a chroot on Linux and > OSX, so that the fake working directory that tup uses is not visible to the > sub-process. This may be necessary for commands that read the current > working directory and write that information in any output files. For > example, gcc with the --coverage flag will use the current working > directory as the location of where to put the .gcda file. Use the 'c' flag > to always run this command in a chroot. This is only supported if the tup > binary is suid root so that it can setup the chroot environment. > I've found that this noticeably slows down my builds, so I general have a > "release" and "debug" builds, which something akin to: > > ifeq (@(DEBUG_SYMBOLS),y) > : <objs> |> ^c LINK %o^ .... > else > : <objs> |> ^ LINK %o^ .... > endif > > > > On Wed, Apr 2, 2014 at 6:45 PM, Jim Lloyd <[email protected] <javascript:> > > wrote: > >> I've been actively using Tup for a couple months on a MacBook running >> Mavericks, and have used both clang and gcc 4.7 via homebrew. I managed to >> go that long without using lldb/gdb for any real debugging, thinking that I >> would be moving to Linux soon and my problems would be solved. I moved to >> Linux today and my problems followed me. >> >> My first problem is probably a mistaken assumption based up misreading >> documentation. I had assumed that FUSE was only used on the Mac. I had the >> impression that on Linux it wasn't needed, and that inotify was used >> instead. Is there a way to not use FUSE? >> >> If FUSE is required, are there some tricks to make it easier for gdb to >> find source files? I know that I can do 'set directories <path>' inside gdb >> to locate the sources, but I want something more automatic. >> >> Thanks, >> Jim >> >> -- >> -- >> tup-users mailing list >> email: [email protected] <javascript:> >> unsubscribe: [email protected] <javascript:> >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- 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.
