[opensource-dev] Review Request: Enable legacy viewer C++ tests in indra/test.

Nat Goodspeed nat at lindenlab.com
Wed Oct 5 10:42:00 PDT 2011


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/479/#review1043
-----------------------------------------------------------



indra/test/llsd_new_tut.cpp
<http://codereview.secondlife.com/r/479/#comment1048>

    Thumbs up for solving this up at the top rather than cluttering code inline. But I think I'd rather see 'using std::fpclassify;' on non-Windows, then put this local fpclassify() in the local namespace, and skip the std:: prefix when calling fpclassify() below.



indra/test/llsd_new_tut.cpp
<http://codereview.secondlife.com/r/479/#comment1049>

    Hmm, where did this code come from? Server side?



indra/test/llsdmessagebuilder_tut.cpp
<http://codereview.secondlife.com/r/479/#comment1050>

    Srsly?? I'd much rather see the definition of _PREHASH_Test0 et al. change to make this work. Are those local?


- Nat


On Oct. 4, 2011, 10:23 a.m., Log Linden wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/479/
> -----------------------------------------------------------
> 
> (Updated Oct. 4, 2011, 10:23 a.m.)
> 
> 
> Review request for Viewer and Nat Goodspeed.
> 
> 
> Summary
> -------
> 
> As part of the Linden Lab automation hackathon, I finally had time to re-enable the tests located in the indra/test directory. These tests are currently not being built or run as part of a standard viewer build and haven't at least since we switched over from subversion. I copied over a few tests from the corresponding server test repository and also fixed some tests that had been rendered unbuildable by various code changes to the viewer. These tests can be disabled from running (but not building) by disabling the standard LL_TESTS cmake configuration variable.
> 
> llevents_tut.cpp proved to be an interesting challenge to get to pass on our Linux build servers.  With the Debian Lenny version of the gcc build toolchain, if an exception is located in a different dynamic library (.so) file as the code that is causing the exception, the exception will not be caught. My workaround was borrowed from the llmessage unit tests and expanded upon to allow the monitoring of the string from the caught exception.
> 
> 
> This addresses bug STORM-1634.
>     http://jira.secondlife.com/browse/STORM-1634
> 
> 
> Diffs
> -----
> 
>   indra/test/llevents_tut.cpp 656d988266e8 
>   indra/test/llapp_tut.cpp PRE-CREATION 
>   indra/CMakeLists.txt 656d988266e8 
>   indra/test/CMakeLists.txt 656d988266e8 
>   indra/test/io.cpp 656d988266e8 
>   indra/test/llhttpclient_tut.cpp 656d988266e8 
>   indra/test/lliohttpserver_tut.cpp 656d988266e8 
>   indra/test/llsd_new_tut.cpp 656d988266e8 
>   indra/test/llsdmessagebuilder_tut.cpp 656d988266e8 
>   indra/test/lltemplatemessagebuilder_tut.cpp 656d988266e8 
> 
> Diff: http://codereview.secondlife.com/r/479/diff
> 
> 
> Testing
> -------
> 
> I built and ran this code on recent versions of all three platforms with no error. When it failed to build in teamcity, I also built it on a lenny system by hand until I had fixed the exception handling issue, then ran all of the tests 100 times in a row on the same lenny machine with no test failures. The tests have run successfully in Teamcity for each revision since the fix for the exception handling code. 
> 
> 
> Thanks,
> 
> Log
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111005/ceb8936b/attachment.htm 


More information about the opensource-dev mailing list