With the paging volume work merged to the trunk and the conversion to Git now complete, it seemed like a good idea to update everyone on what we are planning next. Now that people can create their own repositories for experimenting with new features, we have decided to focus our own work on stablising and polishing the existing code, and working it into a state where we can make an official release (rather than just snapshots).

This will involve a lot of tidying up of the code, including running it through automated code quality tools. We need to fix all the warnings, rearrange and possibly rename classes/headers, and move some things between PolyVoxCore and PolyVoxUtil. We also need to add unit/regression tests, examples, and documentation. And we'd like to spend some time with the profiler trying to improve the areas we have issues with performance.

There won't be many new features for the release, but there are a few things we still have in mind. Possibly interating a decimator into the CubicSurfaceExtractor as the current performance isn't very good. Possibly adding a SimpleVolume as an alternative to the paged version. Maybe other small things, but overall the focus will be on polishing what we already have.

I think this will take quite some time (probably a few months). We'll try to keep this thread up to date with our progress.

Ok, I think one of the first issues to consider is whether PolyVox should ship as static or dynamic libraries. Currently it defaults to dynamic libraries, but it was recently requested that we switch to static libraries (at least on Windows) and I am inclined to agree for the following reasons:

• Simpler redistribution of applications (no .dlls).
• dllimport/dllexport is messy on Windows (not needed on Linux) and gets in the way of SWIG a bit.
• PolyVox is mostly headers and templates - the amount of compiled code in a .dll hardly seems worth it.
• Dll's are unlikely to be shared between multiple applications anyway. For drivers and the like it makes sense to have the code somewhere shared like a .dll in Windows/system32, but for PolyVox?

So, does anyone have any objections to switching to static libraries on Windows?

On Linux the above points still apply, but there are other considerations:

• More common to install libraries to a global location (/usr/lib/...)
• Application more often built from sourcecode?
• No dllimport/dllexport complications, so it's almost no extra effort to support dynamic libraries.

Overall, I suggest supporting only static libraries on Windows, and supporting both on Linux but defaulting to static.

Thoughts?

I agree static libraries would be more convenient than DLLs. PolyVox is quite small so shouldn't bloat the resulting binary by too much. With the zlib license there's none of the annoying issues with using statics like with LGPL.

Can't think of any downsides, really.

I was even fine with making polyvox a template lybrary (headers-only) so I'm all for static libraries, too After all, thil library will often be tightly coupled with the main engines of the program, that's why I was fine with it being header-only. Sure, compiling takes a bit more but this way it's just easier to plug it in your code.
But I don't care this much about it right now, I'm working on my own stuff that is not 100% polyvox-dependant.
After all, I guess that letting the user choose whenever possible it's a good idea, so if we can go static as first choice but leave the option for dynamic linking even under windows, I guess everyone would be just happy. Will it be difficult to have both under windows?
How about making a header-only trunk, too? How much work is needed? a huge load of work or what?

Ok, sounds like people are in favour. I'll see if Matt has any Linux-specific comments and thn make this change.

I'm not so keen to go header-only at the moment for a couple of reasons. Firstly I don't know an elegant way to handle the static data such as the Marching Cubes look up tables. If you put this into headers then it gets built into each compilation unit, and the you get multiple definition linker errors.

Secondly I'm not sure what will get added to PolyVox in the future - maybe it doesn't make sense to be header only then.

SDK
On Linux the story will have to be a little different. The SDK will be released as an RPM (and maybe .deb) for the various distros. Most distributions have a policy of "dynamic libraries only" but I do agree that for PolyVox's SDK it makes sense to have static libraries as well. So on Linux, the SDK package will include both static and dynamic libraries.

Source distribution
As I understand it, Windows and Linux differ in an important way with respect to static and dynamic files (see this for details). On Linux they exist as separate files: the static file is libPolyVox.a and the dynamic library is libPolyVox.so -- they have different file extensions. On Windows you cannot have both static and dynamic libraries in the same place since the name PolyVox.lib can refer to either a static library or an import library for PolyVox.dll.

On Windows we need to chose which (default) we prefer and it seems it's static libraries. On Linux we can easily create both and let the user choose which they prefer at their own build-time.

In CMake, it's easy enough to make this easy so that Windows users can choose to switch to building DLLs at compile time with a CMake option like BUILD_STATIC=YES (default and takes priority if set to YES) or BUILD_DYNAMIC=YES. On Linux by default they will both be set to YES and either can be disabled with BUILD_STATIC=NO.

In summary: Dave, feel free to change the default to static whenever you like and then when I get a chance I'll whip together some CMake code to allow setting these options.

_________________
Matt Williams
Linux/CMake guy

Ok, I've committed the changes so the PolyVox now gets built as a static library. Matt - it's hard-coded into the CMake files so you can just replace that whenever you get a chance. I also replaced the export macros with the examples I found here:

http://gcc.gnu.org/wiki/Visibility

PolyVoxUtil also now uses the same definitions as PolyVoxCore. To do a shared build in CMake you will need to:

• Define POLYVOX_SHARED
• Define POLYVOX_SHARED_EXPORTS
• Define POLYVOX_SHARED in the application which uses PolyVox
• Copy the .dlls in the install script (I just comment this out)

Ok, I've checked in the change in to Git now.

I've tested all the combinations I could think of in Linux and run the tests to check and it all seems fine. If you could try it in Windows to make sure everything is ok?

I set POLYVOX_SHARED_EXPORTS but not POLYVOX_SHARED since I'm not sure how it should be set. Is it the case that: When building libPolyVoxCore.so they should both be set and code which links against PolyVox (does it matter whether it's linking in the static or against a dynamic library?) should set POLYVOX_SHARED?

Since on Linux these are not necessary to make linking work I can't be sure that it's working. Does the attached patch look correct?

_________________
Matt Williams
Linux/CMake guy

I'm having some compile problems under Windows. I have my code in:

C:\code\polyvox

And I'm building in:

C:\code\polyvox\build

The libraries get created in:

C:\code\polyvox\build\Debug

But the basic example doesn't manage to link with them. The BasicExample links with the following command:

LINK_DIRECTORIES(${PolyVoxCore_BINARY_DIR}/debug ${PolyVoxCore_BINARY_DIR}/release ${PolyVoxCore_BINARY_DIR})

But 'PolyVoxCore_BINARY_DIR' appears to point to:

C:\code\polyvox\build\library

I don't know whether the libraries are builng built in the wrong place (should they be in build\library\debug or just build\debug) or whether 'PolyVoxCore_BINARY_DIR' is pointig at the wrong place?

I'll get back to you about the patch once this is working...

I've just managed this evening to get PolyVox compiling on Windows and I'm seeing something similar. I believe that the libraries should (by default) be built in build/library/Debug. It seems some code was added last year (06ef752) to force the libraries to be built in the root build directory for run-time reasons.

Perhaps the simplest fix is to add ${PolyVox_BINARY_DIR}/debug and ${PolyVox_BINARY_DIR}/release to the LINK_DIRECTORIES() call which will add build/debug and build/release to the link paths. I think this needs doing for the tests too.

_________________
Matt Williams
Linux/CMake guy