Interesting... but maybe it doesn't matter now we have switched to static libs? Perhaps the runtime reasons are no loonger relevant and we can let CMake put the files in the preferred location?

In the case of dynamic linking on Windows, maybe we can just copy the .dlls into the folder of the example? This could be done by the example's CMake script?

You're right that for static linking it won't matter. I'll have a look into getting CMake to automatically copy the DLLs to the right place (they would have to be copied to both the examples' directory and to that of the tests too). It should work as long as CMake can make sure it copies them every time they are rebuilt. A standard configure_file(COPY_ONLY) should do it I think.

_________________
Matt Williams
Linux/CMake guy

I fixed the CMake scripts for this so that it just uses the default directory. It seems to work ok, but I haven't set it to copy the .dlls in dynamic builds yet.

Also, I'm about to break the Linux build - probably quite badly. I've been making some heavy changes in Windows which I know don't compile on Linux, but I don't have an easy way of moving code around other than commiting to Git and then getting it from Linux.

I should have created a seperate repositiry for myself on Git but it's too late for that now. Mayeb I can change it (rebase?) but I'm sitting on too much to want to take the risk. I'll get it fixed as soon as I can.

That's fine. I doesn't matter if the Linux build is temporarily broken. If you fix it in your Linux virtual machine then it should be fine. The nightly build will run anyway so you'll be able to see if it's working elsewhere too.

Otherwise you could push those changes into a remote branch on Gitorious but I don't think that's necessary in this case.

I've started looking into getting the NSIS installer working again but I'll wait until the source layout and installation paths are changed.

_________________
Matt Williams
Linux/CMake guy

Actually it turned out not to be so bad Linux build should be working again.

I've been thinking it's probably time we did another snapshot, as the latest one is now two months old and there have been quite a lot of changes since. I realise there's lots of work to do on the SWIG bindings and SDK, but do you know any reason why we can't do a snapshot? Is everything stable on Linux at the moment?

Everything seems to be working on Linux. It all compiles and the tests pass at least.

As far as the bindings go, everything is working at the moment apart from the surface extractors -- in Python I can create a volume and set/get the values of its voxels. Either way, it's probably best if the bindings are not enabled yet for this snapshot.

_________________
Matt Williams
Linux/CMake guy

You've probably noticed we've got some new warnings in CDash. Whilst the warnings are valid, I don't know why they've only just started showing up?

They appear to have started here: http://my.cdash.org/buildSummary.php?buildid=197171

I had made some commits just before that but nothing that should have affected these files. I also removed some warnings (on Windows at least) in this commit but from the timestamps it looks like this was afterwards (though maybe this is due to US vs UK times or something).

Was CDash ignoring certain warnings before, and it only reports when things have changed?

Also, you'll notice that the AmbientOcclusionCalculator test I added keeps failing. It might be due to different results on Windows vs Linux, or there might be an actual problem with precision or uninitialised variables. I'll look into it.

I've been seeing those warnings on my own builds in Linux since the beginning so I'm not sure why they weren't showing up before. I would say that it's correct that they do show up now even though they're not that useful. It doesn't look like it's possible to explicitly disable just those warnings though.

I did notice the failing AmbientOcclusionCalculator test and I saw that you changed the first of the comparisons to be equal to the Linux result. Now it seems to be complaining about the second one. On my Linux box (similar GCC version but everything else is different) I get the same results as the build box so it seems consistent on Linux.

_________________
Matt Williams
Linux/CMake guy