[opensource-dev] Remaining build issues for 64bit linux standalone out-of-source (without unit tests)

Boroondas Gupte sllists at boroon.dasgupta.ch
Mon Oct 11 13:12:34 PDT 2010

 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
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

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.

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

More information about the opensource-dev mailing list