Hello,
On Mon, Dec 30, 2013 at 8:56 PM, thegreendroid <[email protected]>wrote:
> Hi Tup users,
>
> I am trying to write a Tupfile for facilitating TDD on a C/C++ based
> project.
>
> My Tupfile builds the unit test executables correctly. However, I am now
> attempting to modify the Tupfile to run just the changed unit test
> executables.
>
Tup should already only run the unit tests that have changed (as well as
the ones that failed from the last run). Eg:
: foreach *.c |> gcc %f -o %o |> %B.exe {TEST_EXES}
: foreach {TEST_EXES} |> ./%f |>
(This is assuming each .c file is an independent executable - I'm not sure
how you have {TEST_EXES} setup).
If we have test1.c, test2.c, and test3.c, then on the first build we should
get the 3 executables and it will try to run test1, test2, and test3. If
test3 failed, then another update will only run test3 (which should still
fail). Fixing test3 will again only run test3. Further updates shouldn't do
anything at this point.
If you then edit test2.c, tup should only build test2 and run test2.
Are you finding this is not the case with your setup?
> One way to achieve this is to redirect all execution output of unit tests
> to a results file using a Tup rule like so -
>
> : foreach {TEST_EXES} |> %f >%o 2>&1 |> %f.results {TEST_RESULTS}
>
> And then echo the results to stdout if any of the results files are
> newer than the executables.
>
> : foreach {TEST_RESULTS} |> echo %f |>
>
> However, the first Tup rule above throws an error like so -
>
> [ tup ] [0.105s] Executing Commands...
>
> * 5% 1) tests/obj/unittest.exe >tests/obj/unittest.exe.results 2>&1
>
> *** tup errors ***
>
> *** Command ID=9688 failed with return value 1
>
> Is the test actually failing? If unittest.exe is returning '1', then I
would expect to see this error, since redirecting the output won't change
the return value. This is a good thing since tup will know to re-execute
the test on the next update.
If, however, the unittest.exe is returning 0, then this probably means
there's a bug in tup (I'm guessing you're on Windows?). I tried this in
win7 and it seemed to work, but the DLL injection does have some issues.
> Am I going down the wrong path and using Tup in a way that was not
> intended here? I'd appreciate any alternate suggestions/ideas to achieve
> the end result. All I am after is for the compile, link and execute cycle
> to be lightning fast to facilitate Test Driven Development.
>
Instead of this:
: foreach {TEST_EXES} |> %f >%o 2>&1 |> %f.results {TEST_RESULTS}
: foreach {TEST_RESULTS} |> echo %f |>
Try this:
: foreach {TEST_EXES} |> %f |>
The test output will already be displayed, and only the changed / failed
tests should be executed.
If you do need the test results in a file for some other reason, it might
be easiest to use tee rather than a separate rule for display:
: foreach {TEST_EXES} |> %f >%o 2>&1 |> %f.results {TEST_RESULTS}
Let me know if that helps! A lightning fast edit/compile/test cycle is
definitely a worthy goal :)
-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/groups/opt_out.
