As we are now starting to push towards a release of PolyVox I'm working on cleaning up some of the CMake files. As part of this I wanted to make use of some of the new features in CMake 2.8 such as USE_FOLDERS and feature_summary(). These are both new in CMake 2.8.3 and so from now on the version of PolyVox in Git will require this version of CMake. It was released in November 2010 so it's been around long enough for it to be reasonable to expect people to be able to upgrade to it.

_________________
Matt Williams
Linux/CMake guy

It seems that this broke the nightly CDash builds as that machine only has CMake 2.8.2. I'm away at CERN at the moment but when I get home this weekend I'll update it so that it builds again.

_________________
Matt Williams
Linux/CMake guy

Yeah, I noticed that. Just fix it whenever you get a chance.

There also seems to be a problem with the build dependancies, in that on Visual Studio it does not know that it has to build PolyVoxCoreStatic and PolyVoxUtilStatic before building the examples and tests. There was always a problem here with the Python bindings not being dependant on the library, but now it seems to be an issue for everything else as well.

I'm not seeing the problem on Linux though, and I just did a clean build. If you don't have Visual Studio to hand then just tell me which keywords/constructs are supposed to handle this in the CMake file and I'll try to figure out where it's going wrong.

The problem with the tests and examples not being rebuilt properly was my fault caused by me renaming some CMake variables. However, I'm not seeing the problem with the Python bindings. If I do a full rebuild of everything then modify Vector.h and run 'make' I see that the bindings are rebuilt correctly. What steps do you perform to see the bug on Windows?

_________________
Matt Williams
Linux/CMake guy

The Python bindings are indeed rebuilt when vector.h changes, but the problem is that they are rebuilt first (i.e. it's a problem with the build order). If I get a fresh checkout and build from scratch then the process starts by compiling the SWIG bindings, but it then fails to link them because it hasn't built the main library yet. This problem doesn't occur with a rebuild because it just links against the old version of the library.

But actually I think I know what the problem is... the various examples and tests all make use of 'ADD_DEPENDENCIES' to ensure the library is built first. I guess this needs to be added for the Python bindings?

Edit: Just a note that it does apear to work properly on Linux even with a fresh checkout. I guess the default build order is different there?

ADD_DEPENDENCIES shouldn't be needed since CMake uses the fact that one library links against another to sort the build order. Obviously on Windows this isn't happening and it's most likely due to the hack we include to allow choosing between building static or shared libraries (or both). In this case, adding a conditional add_dependencies like in tests/CMakeLists but with ${SWIG_MODULE_PolyVoxCore_REAL_NAME} instead of ${executablename} will hopefully help.

Give that a try and see if it fixes the problem.

_________________
Matt Williams
Linux/CMake guy

Shouldn't that be true of the tests and examples as well though? Maybe we can remove those too? I'll try to have a play with this tomorrow and see if I can fix it.

We talked previously about not providing the dynamic version under Windows as we didn't have a clear reason why it was useful (and it complicates things). I'll see what I find out, and maybe it's easier to remove this.

Hmm, it seems that they're required there too. If I remove them from the examples and run make BasicExample then it skips building the core library and fails at link-time. This is definitely being caused by the static/shared hack. I've now added the code required to manually specify the dependency for SWIG so it should be fixed.

Yes, I remember and this is why the defaults are currently that on Windows, only the static version is built and on Linux, both are built alongside eachother. It may indeed be best to reduce the flexibility so that only one or the other is built and it's impossible to build both at one. I originally wanted to keep the flexibility on Linux but I'm no longer convinced that it's completely necessary. We would then have a single CMake flag which sets which type of library is to be built.

_________________
Matt Williams
Linux/CMake guy

Are you referring to the fact that we are able to build both static and shared libs, or to the fact that we can build both as part of a single build?

Great, thanks, I just tested it and it does seem to be fixed.

I think this will be fine. We've already established that it's hard to build both at the same time on Windows because both static and shared builds generate a .lib file. If we make the choice between static and shared via a CMake flag then we can probably bring back the option of dynamic libs on Windows, as well as removing all the add_dependancies and simplyfiying the CMake code. I can see that on Linux both static and shared can be useful (you said that some distros prefer shared) but I can't see why a user would want both available at the same time.

The only concern I have would be regarding testing because we have to remember to test both builds. But I don't think there's many problems which would affect just one of the build types.

I'm referring to the fact that we can build both as part of one build by setting both ENABLE_SHARED_LIBRARIES and ENABLE_STATIC_LIBRARIES to true.

I agree. In this case I will this evening make a branch (I'm playing with git-flow locally) in my checkout and simplify all this down so that in any one build you have to choose between static or shared.

In my mind, the original reason why on Linux I wanted the option to build both at once was for Linux distros to be able to build a package where both are available since they don't know which type the user will want. However, it is slightly unconventional to provide static libraries here and so I don't think it's a great loss. Also, PolyVox is easy enough to include directly into your project or build yourself that I guess many people will do that anyway (especially for games).

I can't imagine that there will be any differences in functionality (i.e. bugs) between the two and so I will probably not bother doing both in the nightly builds but we should check them manually from time to time to make sure that they both work properly (I'll continue to use dynamic libraries on Linux).

_________________
Matt Williams
Linux/CMake guy