Boost Interest :
From: troy d. straszheim (troy_at_[hidden])
Date: 2008-07-02 14:25:34
Miguel A. Figueroa-Villanueva wrote:
>>> - Is there a CDash dashboard actively running? It seems that the
>>> http://dart.resophonic.com/boost_1_34_0/Dashboard has been down for
>>> the last 4 days at least...
>> Troy's been working on an updated system that isn't based on CDash. I
>> haven't been keeping up with it as well as I should, but I expect
>> we'll see more cool stuff from him later on.
> I'd like to know the details here... if it is ctest/CDash I can help
> to set these up and later in august I could probably setup a public
> dashboard (Now the network administrator that is in charge of the
> equipment is in vacation and I need him to resize the virtualized qemu
I think what we're doing here is pretty compelling. The working title
is 'traash' (trac + dash). We're *not* using ctest/cdash/dash or any of
that. See the archives for this list, there are some long threads there
that explain the reasoning. See also
tools/build/CMake/BoostBuildSlave.cmake, and the various python scripts
that do the low-level work: tools/build/CMake/*.py.in. There are user
and the 'dashboard'/trac plugin is at
There is a 'build slave runner' script named run_continuous_slave.py
that is put into your build directory that runs incremental builds
similar to how 'ctest -D Continuous' does. This business of setting up
build slaves, continuous/nightly builds, configuration, etc, tends to be
brittle but needs to be solid as a metal desk... a lot of the users
won't be experts. Any development/testing/documenting that you might
feel like doing here is most welcome.
The dashboardish trac plugin is slow (for various fixable reasons) and
needs more features (it only has a couple of views), but it is easy to
extend and I already find it useful. I think it won't be long before we
are more effective at communicating the current state of the release
branch than the current testing system is, even with far fewer people
and machines. I expect this to be a big help making our case.
The long-term intention here is to factor out the client-side
cmake/python infrastructure and post the trac plugin on trac-hacks,
making this thing generally available to cmake/trac based projects.