Hi guys, I've finally fixed PolyVox so that it builds on VS2012. It was a trivial fix but of course you don't know that until you start...

The resolved issue is here: https://bitbucket.org/volumesoffun/poly ... -on-vs2012

As discussed on our blog, we're switching to a more 'relaxed' attitude to PolyVox development. Therefore I do not expect to test PolyVox any further on earlier versions of Visual Studio and will do all my work on VS2012, adopting C++11 features as desired. Matt is on Linux so GCC will carry on working.

If you wish to continue using VS2010 then you should consider this commit to be the last one where it was tested and is known to work.

And just for the record, PolyVox is currently still working with GCC 4.4 but it's quite likely, based on the things David mentioned in the blog post, that the requirement will be upped a few versions by the next release.

It also build fine with Clang 3.3 and probably also a few older versions.

_________________
Matt Williams
Linux/CMake guy

I see I broke the nightly build by using 'nullptr'. It seems this was only introduced in GCC 4.6... is this a reasonable requirement or should we use a workaround like this?

I don't think it's anything to worry about. We can up our requirement to GCC 4.6 without worry as it came out about 3 years ago. If it causes problems for anyone, it can be fixed with a typedef of nullptr to 0 without worrying about it obeying the proper nullptr semantics. There's almost certainly things in the dual-contouring branch which will not work with GCC < 4.6 anyway.

I'll fix the nightly build to stop trying with the older GCCs as soon as I get a chance.

_________________
Matt Williams
Linux/CMake guy

It turns out that the build machine we've been using for the last few years doesn't have the latest versions of GCC on it and only goes up to 4.5. Luckily, I've got a VPS on which I've been setting up a Buildbot. You can see what I have so far at http://milliams.com:8010/waterfall (ignore the test failures). Since it's completely under my control, I can easily update the compilers and packages to have everything we need available.

As it's very configurable I can set it to that it can automatically build any feature branches and run the build automatically whenever a change is committed. Also, it can also be a bit more intelligent about interpreting the test results so that we will no longer have to do the strange thing in tests/CMakeLists.txt where we declare all the tests multiple times.

Given this, I have disabled the CDash dashboard for now. I will be working on the Buildbot for a while until it's working as I want, at which point we can host the web front-end at volumesoffun.com if we wish.

_________________
Matt Williams
Linux/CMake guy

Sure, this sounds fine, and being able to run tests against feature branches could certainly be useful. Does it replace CTest, or Qt test, or just CDash? I look forward to seeing it working, apologise in advance if I break the GCC version before then :-)

It doesn't replace Qt Test or CTest, simply the CDash dashboard. However, there's no reason we couldn't potentially replace one or both of those in the future if there's something which works better. The nice thing with them at the moment is that they can output XML which is easily parsable by the Buildbot plugin I wrote.

_________________
Matt Williams
Linux/CMake guy