On Fri, 2009-06-26 at 14:38 +0200, Patrick Ohly wrote: > TODO: > * add -Wall -Werror: compiler warnings are not acceptable.
Done, by changing the --with-configure parameter that is passed to runtests.py in my personal "runtest" script on the test machine. The gcc on Lenny suggested adding some parenthesis to the Synthesis source code, which I did. Another warning was about an uninitialized variable, also fixed. > evolution: these are the local tests. They are always done, in contrast > to the server tests. It failed on this test account because it didn't > have any of the default databases (testOpenDefault*). Fixed. > scheduleworld, synthesis, funambol: these are the sync tests. The > selection of enabled tests for each server is done in test/runtests.py. > Most of the tests failed because of "config.dump" not set. This is a > problem in client-test itself, will fix it. For example: Client::Sync::vcard30_ical20_itodo20_text::testCopy This test runs a sync with all four sources active, in this order. In order to test this combination, all sources must support the testCopy test. This wasn't the case (accidentally!) for text because the config.dump method wasn't set. Fixed. For single-source tests this precondition is tested before adding the test, so there was no Client::Sync::text::testCopy. But with multiple sources only the first was checked, leading to an assertion when running it. > Running all sync tests can take a while and create a considerable load > on the servers. ScheduleWorld is most affected by this because it has > the most tests to cope with. Running it too often is not acceptable; > traditionally it was done once per day at a time agree upon with Mark. > > TODO: > * Need to check how often we can run the tests nowadays and at > which time. > * Add testing on other distros (currently running on Debian Lenny > + Evolution 2.22.3.1) via chroot envs. > * Enable valgrind checks. Done for Lenny, with the valgrind version provided by Lenny. A valgrindcheck.sh wrapper script tells valgrind to write a log file and then checks that the file contains no warnings. The problem with valgrind is that we also trigger warnings in system libraries. These warnings depend to some extend on the valgrind version and to a larger extend on the system libraries and Evolution. There is a set of suppression rules in our test directory: sys.supp - system libs, mostly for Debian Etch evo.supp - Evolution libraries client.supp - Funambol C++ client library In the past with Funambol as SyncML library it was very difficult to check for memory leaks caused by C++ code, because that library leaked it lot of small chunks. Therefore checking of *all* memory allocated via new was suppressed, even if done by SyncEvolution. I'm no longer using the client.supp file, so let's see how we fare now... ;-) Given that SyncEvolution uses the RAII paradigm (memory is never freed manually), I don't expect too many leaks, except in places where it is not clear whether we become the owner of a resource. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list SyncEvolution@moblin.org https://lists.moblin.org/mailman/listinfo/syncevolution
