Hi Mike,
I tried implementing your suggested solution but I am now running into an
error -
On Linux (with tup version 0.7-30-gfa1b078) -
tup error: Unable to create command 'unittest' because the node already
exists in the database as type 'generated file'
tup error: Error parsing Tupfile line 11
Line was: ': foreach {TEST_EXES} |> %f |>'
[ ] 100%
*** tup: 1 job failed.
On Windows (with tup version v0.7-33-g8981d64) -
[ tup ] [0.052s] Executing Commands...
* 11% 1) tests/obj/unittest.exe
*** tup errors ***
*** Command ID=9773 failed with return value -1073741515
Unitttest is returning 0 if I run it manually so it is not failing.
Any ideas? Also, why is the Linux version older than the Windows one? I
installed it through apt.
Thanks for your help.
On Friday, 3 January 2014 06:06:53 UTC+13, [email protected] wrote:
> Hello,
>
>
> On Mon, Dec 30, 2013 at 8:56 PM, thegreendroid
> <[email protected]<javascript:>
> > 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.
