On 10/11/2010 03:05 PM, Oz Linden (Scott Lawrence) wrote:
>>
>> VWR-23296 <https://jira.secondlife.com/browse/VWR-23296>: missing
>> LL_TEST conditions (i.e. SNOW-651
>> <https://jira.secondlife.com/browse/SNOW-651> *+* SNOW-654
>> <https://jira.secondlife.com/browse/SNOW-654>)
>>
>> * The ability to turn off building and executing of /all/ unit
>> tests is needed to work around other issues (which we'll have
>> to fix later)
>> * Fixed at http://bitbucket.org/boroondas/vwr-23296
>> * Should be easy to review (but note there are several changesets)
>>
>
> I'm hesitant to move this to the main development branch, because I'd
> rather not make it easy to not do tests. If they're broken, we should
> instead invest in fixing them (or the means of running them).
As I've already stated in a jira comment
<https://jira.secondlife.com/browse/SNOW-651?focusedCommentId=199198&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_199198>,
I don't think this is a question of either-or. As long as we /have/ the
LL_TESTS option (and I haven't introduced it, it was already there), it
should do what its name suggests. *This shouldn't stop us from fixing
the tests.* In fact, my plan for the time after having gotten all build
fixes I need with LL_TESTS set to FALSE into viewer-development (which I
hope will be soon) was to set LL_TESTS back on TRUE and hunt down the
change(s) needed to build like that. (We already had these fixes in
Snowglobe 2. I hope nothing new got broken regarding unit tests, since
then.)
Even once the tests can be run on all platforms, we /might/ want to keep
the LL_TESTS option around for the following cases:
* Developer A breaks a tests, but this only manifests on Developer
B's platform (thus A didn't catch it during his/her own builds).
Developer B isn't able to fix A's mistake (not B's area of
expertise), but would like to continue his/her own development
based on the newest code and of course test whether it at least
builds (and maybe test new or fixed functionality). B would file a
bug about the broken test (probably to be fixed by A), set
LL_TESTS to FALSE and continue development. Hopefully, the broken
test gets fixed before B's development is ready for integration,
so B can then set LL_TESTS back to TRUE for a final test before
his/her stuff ends up in viewer-development. If the test can't be
fixed in time, the test-breaking commit should probably be backed out.
* Developer C has a slow machine and is working on something of
which he/she assumes that it isn't unit tested anyway, yet, or
that his/her change is easy and save enough to be very unlikely to
break any tests. During development, C does several builds with
LL_TESTS set to FALSE to get shorter build times. Only before
requesting integration, C does a final build with LL_TESTS turned
back on.
Of course, for the first scenario, it would be good to be able to only
disable the offending test and keep the other tests in place. But for
now, the all-or-nothing LL_TESTS is what we have. (Short of editing
CMake scripts.)
> I'd like to hear more discussion on this... specifically, what are the
> problems that are causeing the tests not to be useful?
They would be useful if the system for running them wasn't broken. When
I set LL_TESTS to TRUE, I currently get errors like this:
[ 10%] Generating PROJECT_llmath_TEST_llbboxlocal_ok.txt
LD_LIBRARY_PATH += ['/usr/lib']
LD_LIBRARY_PATH = '/usr/lib'
Running: ${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal
--touch=${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt
--sourcedir=${SRC_DIR}/indra/llmath
${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal: error while loading
shared libraries: libllcommon.so: cannot open shared object file: No such file
or directory
Failure running: ${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal
--touch=${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt
--sourcedir=${SRC_DIR}/indra/llmath
Error: 127
make[2]: *** [llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt] Error 127
make[1]: *** [llmath/CMakeFiles/llmath_tests.dir/all] Error 2
make: *** [all] Error 2
I.e., LD_LIBRARY_PATH is missing some entry. When building parallel, I
see equivalent errors about other unit tests.
Why should we fix VWR-23296
<https://jira.secondlife.com/browse/VWR-23296> first and the unit test
execution later? Simple: As long as unit test execution is broken, it's
easier to tell whether we've fixed VWR-23296 completely (i.e. have
wrapped ALL adding of test targets into LL_TESTS conditions). Not that
grepping for "\o/" would be difficult, but yeah ... you get the idea.
Cheers,
Boroondas
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
