It seems that most of PolyVox already exists in headers except some huge tables. It could be worth making thing work when functionality using these tables (maybe it already does?).

On a related note, CMake should build static libraries by default, at least for Visual Studio.

I agree with you about the static libraries - the advantages of shared libraries (sharing code between applications, ease of updating, etc) don't really make sense in a library like PolyVox. Plus static libraries are just easier to work with because you don't have to remember to copy the right .dlls into your working folder, etc.

Not so sure about making it header only though. Those tables are key part of the library and I don't know of a better way to store that static data. Plus the library isn't finished yet, so there's every chance that header-only will make less sense in the future.

Once we have moved to Git I intend to focus on tidying up PolyVox rather than adding new features. That's the point at which I'll consider the above, and will ask if anybody has any objections to switching to static libraries at least by default.

I'd appreciate this immensely; not having to build it separately but simply including PolyVox in my projects would cut down on time spent getting it working, giving me more time to implement whatever I'd like to use the library for (thus improving the drag -> drop aspect a lot).

I'll get it working over the next few days surely but pulling from git (or downloading a .zip and extracting it) and adding "#include PolyVox/PolyVox.h" would be a lot easier.

It is for this reason that we're working on an SDK with with the library pre-built inside. Follow the progress in the thread.

_________________
Matt Williams
Linux/CMake guy

Well, that's good to see. Cheers, milliams.