So three months ago I created a CDash -based site for performing Contiunuous Integration (CI) with NeL . I created a little document and posted a news post and a forum post requesting volunteers to "donate" server time to do builds and unit tests for our site. To date I have received no volunteers. Fortunately my host for opennel.org's server has made some moves of my machine and I now have a little more liberty to consume CPU cycles and memory. So I have configured NeL's dashboard builds on my host. If you look at the NeL Build Dashboard you will see that I am now doing Continuous builds as well as Nightly builds. I'm still hoping for a host that can do Nightly builds using VS2008.
I'm really hoping that once I start getting a variety of hosts and compilers submitting builds to this site that the number of incidental errors we create when developing for a specific platform will begin to fall. There are a number of instances in which a unit test is broken on gcc when coding using the benefit of a known compiler quirk in Visual Studio, for example. In the early days of NeL development, especially after we forked to OpenNeL, we encountered these kinds of incidental errors often. This was also back when Visual Studio was less strict and gcc was beginning to be much more strict.
On that same note we face this problem with gcc as well. A great number of distributions are using gcc 4.3 for example while my builds are occuring on gcc 4.4. We've seen each version of gcc become increasingly strict in its compliance to the standard. In some versions so much so that NeL even refuses to build on the newer version until we remediate the violations. As long as we continue to have a mixture of compiler versions CI will help facilitate at least rudimentary regression testing for situations such as new code created against a less strict version or changes to bring code into compliance potentially breaking builds on other platforms.
Other than our lack of both platforms and compilers represented in our CI environment the other major problem we have is a significant lack of unit tests. We have a number of unit tests in NeL but we have had no such test-driven-development (TDD) philosophy in the development of the libraries, tools or applications. Especially the applications which have devolved into a hodgepodge of questionable patches. Hopefully in the near future we will also expand our unit testing into areas and applications which have no representation in testing.
If you're a NeL user or developer please consider donating your system time to our CI environment and please keep a close eye on the NeL Build Dashboard for errors and warnings. We always gladly accept patches .