It's no problem, I get warnings in Visual Studio too so I can fix most of them there.

It's great your doing this - I can see there are a lot of commits going through! I feel a bit bad I'm not having time to work on it myself at the moment but it should all quiet again in a month or so...

If I get time tonight, I might have a go at getting CMake working properly in Windows with VS 2008 or 2010RC.

Don't worry about not having much time. I'm just trying to neaten up the build system and the testing side of things. Next week I'll see about writing more more extensive unit tests.

_________________
Matt Williams
Linux/CMake guy

I have made some progress here - I used the links you provided to install the libraries and executables to the same folder on Windows. It is better now

It did sucessfully submit a CDash result but it seems the tests didn't actually run. I'll look into this when I get a chance.

Actually, it only works properly in release mode. In debug mode we append the '_d' to the end of the library name and I think this is why it doesn't find it.

Do you think we should keep this '_d' thing? In some ways it is nice to manually tell debug and release versions apart, though I'm not sure I've actually needed it in practice. Some other projects do this, but on the other hand should we really care about the difference? I think they should be interchangable anyway...

Does Linux have any stabdard approach to handling release vs. debug libraries?

(sorry for the long post...)

Good, I'm glad that was the main problem and not something terribly complicated.


I see the submission. Looking at the test report it looks like it simply didn't find the test binary. This is due to a mismatch caused by the binaries being built in a different place and the CREATE_TEST() macro I made not knowing this. I'll need to work out which variable really describes where the files are written.

I'll need to read into the various bug reports about this stuff but it looks like your problem with RUNTIME_OUTPUT_DIRECTORY not working in Windows might be fixed in CMake 2.8. Furthermore, it might get even easier in 2.8.1 (see this bug) which should be released some time very soon. If you get a chance, could you try it with 2.8 to see if you fare any better? We can always raise the required version if necessary (and will need to for VS2010 anyway).


Yes, and also it's probably going to try to put it in a /Debug directory or something given the chance


The two should be binary compatible, yes. I guess that really, most of the time, you simply use one or the other and don't switch between the two that often. If they're still being output to a Debug or Release directory then I guess the _d suffix isn't really necessary. It could simplify things to get rid of it.


In Linux we don't tend to bother with 'debug' libraries. Any library we get from our distro will have been build with the RelWithDebInfo CMake build type which sets -O2 -g. This means that it's optimised but not to the point of mangling line numbers and symbols and the -g means that debug symbols are included. Then, before it's all put into an RPM, the debug symbols are stripped out and put into a separate package. This way we can run with almost fully optimised libraries but can get the debuginfo if we really need it.

The Debug build type will just set -g so there is 'no' optimisation in order to get most accurate symbol locations. This isn't used much since RelWithDebInfo is usually fine.

Finally, Release sets the flags -O3 -DNDEBUG which obviously optimises more but also sets -DNDEBUG which turns off asserts etc.

So really the only difference between release and debug (RelWithDebInfo) builds is a little bit of optimisation, inclusion of debug symbols and the lack of asserts. Because of this I think that most people developing against a copy of PolyVox they built themselves would build PolyVox with RelWithDebInfo and then only switch to a release build if they were then going to include the library (static or shared) along with their project.

I don't know how that all differs from Windows though? You can see what would be set for the different configurations by looking in ccmake or cmake-gui at the CMAKE_CXX_FLAGS_<config> variables.

_________________
Matt Williams
Linux/CMake guy

Unfortunatly the other project I am working on uses VTK (and so also CMake) and I can't really risk breaking anything at the moment. I'll try upgrading as soon as I can...



Maybe that's best... again when working with VTK I notice they only have one version installed at a time. That is, switching between debug and release builds involves opening the VTK solution and builing the appropriate 'INSTALL' target.



I don't think it's that different, I've seen a couple of articles recommending that you even ship your final version with debug info included. The performance overhead is supposed to be small, and the actual debug info is actually in a seperate file (.pdb I think) so it doesn't add much to the file size. But ultimatly we are only making this choice for any binaries we ship - an end user building from source code can choose which ever build type they want.

That said, I do find on Windows that debug builds are *a lot* slower than release builds (by an order of magnitude maybe). Don't know about release with debug info. I have been assuming the reason is the large number of asserts in the PolyVox source code. There are asserts to validate the parameters every time a voxel is read or written, and this happens a lot. Of course, it's a good thing from a robustness point of view but if asserts are the performance issue then we should make sure that ReleaseWithDebugInfo doesn't include them.

I'm away for the weekend now, I'll pick this up when I return...

Well, the CDash dashboard is useful! I forgot to commit a file last night, and this morning I got an email telling me the Linux build had failed. All fixed now

Ok, well there's no rush. Everything's working just fine in Linux with 2.6 so it's only Windows that would be affected.


Well I see you've made this change now. It has no effect under Linux since it doesn't use the CMake 'configurations' thing but I assume it's going fine under Windows?


The .pdb thing sounds almost exactly like what Linux does so that simplifies things. When we get round to another binary release I'll make sure they're built and handled correctly in the CPack installer.


I haven't done any profiling/benchmarking under Linux to compare debug to non-debug but I would imagine it would be the same thing. Having a full debug version (with asserts) around for testing purposes would be useful but I guess for day-to-day developing, RelWithDebugInfo should suffice.


Excellent. I'm glad it works as expected.

_________________
Matt Williams
Linux/CMake guy

Yes, but actually it seems that the debug and release version are not directly interchangable. If you build PolyVox as release/debug then you have to do the same one for Thermite. And actually I'm finding the same thing when working with VTK. It's not really a problem at the moment but I'll look into it at some point


Actually, having to fix the website after the attack reminded me that we have more than a webserver there. It's a general Linux machine really. So if it is a problem for you to be running the CDash nightly builds from university then we can probably do it from the webserver instead. Not sure if we can run tests though. But if it's not problem then it's probably easier to stick with the existing solution.

Ok, as you've already noticed I've finally been back on this. My contract work isn't quite finished but it much quieter now so I've got some time again.

I've updated my system to Windows 7 and Visual Studio 2010. This means I was finally able to remove the awkward C++0x compatability stuff as it builds properly on VS 2010 and GCC. I've also updated to OgreSDK 1.7.1 and took the latest version of Qt from Git (heading towards 4.7 now). Also, my CMake is now on 2.8.1. Just a few more bits and pieces to do to get everything running smoothly again.

Also, I've done some work adding scripting support to the QtOgreFramework. It's very preliminary (I'm still working out how stuff fits together) but I've got keyboard input and wrapped the Ogre::Vector3 class. The camera can now be controlled through QtScript There's lots to do here but it looks promising.

I'm running OpenSuse 11.2 in VirtualBox so I was able to verify those fixes you made (thanks for that!). I was going to fix it myself but you got there first. Shows that CDash is working as expected I'll try to check the QtOgre framework works under Linux after I've made my scripting changes.

This is very good option. It provides many great features and functionalities. It works well. There is no problem related to any platform.

_________________
r4 gold