Windows Build/MSVC

From K-3D

Build Overview

• K-3D version: 0.7.
• Build environment: MSVC with CMake.
• Runtime environment: Native Win32.
• Pros
  • Familiar build environment for Win32 developers.
  • Native OpenGL performance.
• Cons
  • Non-free toolchain.
• Known Issues
  • See below.
• Requirements
  • CMake

Build Instructions

MSVC Issues

• The K3D_COMPILER_NAME macro is a bit broken, since the MSC_VER actually expands to a number and not a string. This breaks bugbuddy/main.cpp (at time of writing, line 216), and is easiest quickfixed by just removing the line or adding a hardcoded string. Resolution: use the stringizing operator on _MSC_VER.

• In user_interface.cpp, the log_handler method, LogDomain apparantly can be null, which isn't checked by the STC++L implementation (or something) in VC causing a crash. Easiest fix is to change the usage of LogDomain to '(LogDomain ? LogDomain : "")' Resolution: like it says.

• In data.h, the value_t typedef in the pointer_storage class shadows the value_t typename definitions in derived classes, which leads to compiler errors. Easiest fix is to change the name of the typedef to something else, like "nonpointer_t". Resolution: like it says.

• Make sure K3D_SYMBOL_VISIBILITY is ON in CMake, otherwise the plugin registration functions won't be exported and plugins will fail to load. Resolution: K3D_SYMBOL_VISIBILITY defaults "ON" if WIN32 and MSVC are true.

• The BOOST_STATIC_ASSERT in the default implementation of almost_equal (in almost_equal.h) gets hit, probably due to GCC & VC having different ideas on how much to instantiate. Easiest quickfix is to change it into a "assert_not_reached()" Resolution: try a slightly different syntax for BOOST_STATIC_ASSERT, since it *should* work correctly with MSVC.

• CMake generates a "windows" project for the main K-3D application, which then expects a WinMain entrypoint. This is easiest fixed by manually switching the subsystem (project properties->linker->system) to "Console". However, this also adds an output console so if that's not wanted, some proper fix (a relaying WinMain or so) must be done. Resolution: create a WinMain().

• For some reason I (Anders Stenberg) have also changed the "int64_t" on the almost_equal<k3d::double_t> constructor argument & threshold member into a "uint64_t". Can't remember what that was about, but it seems more correct anyway. :)

• A problem running the k3d-make-module-proxies executable:
  • http://www.nabble.com/creating-custom-signal-with-Visual-Studio-2005-Pro-t3686518.html
  • http://www.eggheadcafe.com/software/aspnet/29824681/err-iterator-list-corrupt.aspx
  • The problem I'm having now is that the "make-module-proxy" (or whatever the name is) app asserts on some iterator corruption in SC++L, which from some googling seems to be some weird issue that happens in rare cases with VC but no one knows how to work around really.
  • Resolved - the issue actually comes from linking to the optimized GTK libs when K-3D is compiled in debug mode. Debug versions (suffix 'd') need to be used for all GTK libs that have one.

• K3D-png-io project may be linked to png12.lib, and should then be changed to just png.lib