Ok, I think we're in agreement that the choice between shared and static should be made at configure time, and that this will simplify the CMake code. I suggest we do make these changes and see if it improves things.

The only thing that springs to mind is the weird 'dll export' stuff which is required on Windows. So before a stable release we should just check that the required constructs are exported properly for the dynamic version (and we'll see a build error if they are not). I don't expect there to be any runtime differences.

I've now pushed the changes. It removed quite a few lines of CMake code which is nice. You can ignore the various 'merge' commit messages that were pushed, that was just me playing with git-flow locally (it works quite nicely).

I agree, there's a chance that this could cause a problem. We'll just have to make sure that we test these things before a release. As it turns out, the static libraries weren't actually fully working on Linux due to me not building them as PIC (so it failed when they were linked into a dynamic library). I guess it turns out that I hadn't been testing that properly anyway...

_________________
Matt Williams
Linux/CMake guy

Almost perfect... I just had to change one instance of PolyVoxUtilStatic to PolyVoxUtil. Guess this just slipped though but it's fixed now.

There is a remaining problem which I haven't mentioned yet and I think I need to look into it a bit myself. For a long time I've always had to run 'cmake ..' twice when generating Visual Studio solutions from a fresh build. The first time I run 'cmake ..' I get the following error as part of the output:



The interesting thing is, I have two development machines (one with Python/SWIG and the other without) and I've always had this on both machine until recently. But one of the commits you made in the last week fixed this error for the machine without SWIG/Python, so now that machine works properly.

I'm going to go back and try to identify exactly which commit resolved the problem, then we see try and work out why it was an issue and see if something similar needs to be changed in the Python/SWIG part.

I'll let you know when I've done some investigation.

Great, I guess I missed that.

Hmm, this seems like a CMake bug to me, especially if you were seeing it on multiple machines. I don't remember seeing this bug myself when compiling on Windows. Perhaps try updating the version of CMake to see if that helps. Otherwise, at one point I think we were manually setting the executable output location on Windows but now I can't find this so I guess it's been removed.

You should also check (after the first CMake run) where (if it exists) the cmTryCompileExec.exe file is actually located.

But, yes, try to track down the commit that fixed it (I would suggest using 'git bisect' but I think it's too much hassle for this case) and see if that helps.

_________________
Matt Williams
Linux/CMake guy

It seems I might have been mistaken.... after rolling back I can't reproduce the issue. Also, if I add SWIG/Python to the machine which previously didn't have them then this does not cause a problem. i.e. I now have SWIG/Python on both machines but only one is giving issues. I guess it's machine specific so I'll try to compare the output of the two machines to track down the problem.

On an unrelated note, in the summary 'Build bindings' is set to ON if they are to be built but appears to be blank otherwise. I guess it should be set to OFF?

Bugs related to system configuration are a pain to figure out since things can change so easily (especially with semi-automatic updates on Linux) but if you can work out what's causing the problem it would be great as I'm sure a user would hit it as well eventually.

I haven't actually tested that part recently on a machine that doesn't have SWIG installed so I've missed that bug. According to this line it should indeed be set to OFF in that case and I don't know why it's not. It's probably a scoping issue with that variable. I'll take a look tonight if I get a chance.

_________________
Matt Williams
Linux/CMake guy

It does look like it's a problem with my configuration. I tried the most basic CMake script I could find:

And it has the same problem on that machine (but works on my other machine). So yeah... I don't think is going to be affecting other people and I'll probably ignore it.

It certainly seems like CMake is confused about something in that case. Probably the best fix for you is to remove any trace of CMake from the system (including any entries in the path etc.) and install it again from scratch.

_________________
Matt Williams
Linux/CMake guy