I'm running a Jenkins continuous build of Eigen, and my 3.0 branch build recently broke due to a test failure.

Revision e5f87fa9e5c21dc685d9e8ed314df17a1884860c broke my build with Clang trunk, with a failed test 490 - dontalign_7.

The following commit seemed to fix the clang build but break my GCC one (on Ubuntu 11.04 x64) - 6dbc070bef475baddf91aa3c913cebe5aff5d92c
That build failed test 271 - qr_1

Are these tests typically pretty consistent, or could these be transitory errors? (A full rebuild and test run takes quite a while, so I'd rather not do it if this is actually a code issue.)

Thanks for your work on Eigen - it's really great!

Ryan

hm, these are not mercurial revision numbers. It is true some tests might sometimes fail even though there is no real issue. Typically if a test qr_1 fails only 1 run over many, then there is nothing serious. The dontalign test also do a QR factorization, so there is probably nothing serious there too unless they fail on a second run.

Would it be possible to automatically upload the results of continuous builds on our cdash? (I don't know Jenkins, but e.g., after the normal build the commands should run the test and upload the results:

ctest -D ExperimentalStart
ctest -D ExperimentalTest
ctest -D ExperimentalSubmit

using the following command:
ctest -D ExperimentalBuild
instead of make will trigger the build of all tests and report the compilation errors too.

OK, I've re-structured the autobuild I had set up in Jenkins so that it runs cmake, then runs

ctest -D ExperimentalStart -V
ctest -D ExperimentalConfigure -V (so that you see the compiler info and config options)
ctest -D ExperimentalBuild -V
ctest -D ExperimentalTest -V
ctest -D ExperimentalSubmit -V

Is that helpful? They should start coming in under a site named "isu-vrac-vance-autobuilder".

that sounds good but unfortunately it seems that does not work though it still upload something.

http://eigen.tuxfamily.org/CDash/index. ... ject=Eigen

The ctest -D ExperimentalConfigure -V fails if you don't run cmake first. So I think you start with:

cmake path_to_eigen_source
ctest -D ExperimentalStart -V
ctest -D ExperimentalConfigure -V
...


The ctest -D ExperimentalConfigure -V will still output enough information.


Thanks again for your help. Such reports are very useful to us.

Yeah, I was doing CMake first. I hadn't actually run a Linux autobuild since changing the config, since it take so long (was going to let it do the first one overnight), but I started working on doing it on Windows too, which is what ended up showing up on the dashboard. Sorry for the noise...

Is it useful to have debug builds as well, or is a release build good enough?

OK, no problem!

the most configurations we test the better, but I know that building the Eigen's unit tests takes a lot of resources, so a release build is already very good.

OK. Looks like it uncovered a few issues: test failures when building with Clang, as well as some build failures with visual studio 2008.

As an FYI, I found that the workaround for building the tests with CTest actually broke the use of just a simple ctest -D Experimental on my visual studio 2008 machine. I fixed it by passing -DEIGEN_LEAVE_TEST_IN_ALL_TARGET during the first configure (had to start with a clean build dir) and changing the main CMakeLists.txt file so that the ctest area resembled this: https://gist.github.com/fc90fe3463c981b40792 (adding the if(NOT EIGEN_LEAVE_TEST_IN_ALL_TARGET) around the workarounds.) If this can be integrated upstream, I've got a 32-bit and 64-bit continuous build in vs9, 10, and 11 preview already set up that will go when the visual studio 9/32 succeeds.

Very nice. Actually, it seems we already have a nice alternative of this half working workaround:

https://bitbucket.org/hauke/eigen-cdash ... s/overview

I'll try to integrate these changes asap.

EDIT: done.