Tag Archives: CMake

Visual Studio 2012, XP support, and codebases with too many dependencies

The potential of C++11 support first enticed me to consider moving to Visual Studio 2012 for Windows development. (Our existing environment was Visual Studio 2008.) Once I got a moment to actually try it out, the much-improved IntelliSense (that actually debuted in 2010, powered by a modern, capable compiler front-end, EDG) really wooed me. It’s remarkable what not getting flustered by a smart pointer can do for code completion.

Here’s the rub: We have a large immersive system that runs Windows XP x64, and for a research lab that develops software in the course of its work (rather than a software-driven shop), we’ve got a bunch of dependencies. VS2012 does support Windows XP, kind of, but you have to jump through some non-default hoops to get it to work.  I’m happy to announce, however, that I was able to get the whole stack we use for VR JuggLua built with VS2012 using the “v110_xp” XP-compatible toolset. (The linked page has the details on how to check/set the Platform Toolset of VC projects for XP compatibility.)

By far, the easiest way to build is if you have a CMake-based build system available. Recent versions of CMake have added a “Generator Toolset” concept, which can be used to specify the “v110_xp” toolset needed for this instance. There’s no GUI support for this at the time of this writing (CMake 2.8.11.2), but it can be done in the GUI: before initially configuring a build, add a string variable to the cache called “CMAKE_GENERATOR_TOOLSET” with the value “v110_xp”. You might see a spurious warning about this not being used at generation time, but rest assured, it is. (Check in Visual Studio if you’re not confident.)

VR Juggler and its dependencies have been built and posted (as branches) in my vrjuggler-windows-binaries repository. The linked branch includes VR Juggler 3.0.x (built from my CMake-enabled git branch, using CMake) as well as the client-code compile-time dependencies. In separate branches, I’ve preserved all the dependencies separately:

I’ve also built OpenSceneGraph, with a usable subset of its plugins. Conveniently, I realized that third-party libraries with a C-only interface can be built once with MinGW and used across compiler versions (as Zlib does), which helps a lot. (Particularly with the CMake option to spit out an MS-compatible .lib import library file.) I’ve uploaded the OpenSceneGraph 2.8.x v110_xp binaries here.  (Binaries in git repos let me use them as submodules…)

For VR JuggLua to build in all its glory, it needs Qt 4.x, or at least FLTK. FLTK was an easy build, and I got the chance to hammer out a few bugs in that neglected GUI frontend. I did end up being able to get Qt 4.x built, after a bit of pain and uncertainty as to whether it would actually work on XP. I’ll post binaries, or at least instructions, soon.

Did it work? Yep! Got a fully functional VR JuggLua build that successfully runs immersively in the aforementioned WinXPx64 system. It’s not the default for continuous builds (yet), but it’s a lovely step forward.

Making a CMake-based build install software in de-facto standard locations

This post falls partially into the “Note to self” category. I typically set up CMake variables for “bin”, “lib”, “share”, and so on to use when installing software (or building it if I want it to run in the build directory and it’s stubborn about layout). Turns out that there’s a module called GNUInstallDirs that was added to CMake in 2.8.5, and improved since then, that sets these up in a standard-ish way. Furthermore, when distros package CMake, if they don’t follow the defaults, they typically patch this file so it applies, so this really takes care of the whole “what to call the library directory” mess quite nicely.  The canonical source documenting the meaning of these variables comes from the GNU project, but I’ve separated the most common ones below (listed ready to copy-and-paste into your build):

  • ${CMAKE_INSTALL_BINDIR} aka “bin”
  • ${CMAKE_INSTALL_LIBDIR} aka “lib” or “lib64” or something more complicated for Debian multiarch
  • ${CMAKE_INSTALL_INCLUDEDIR} aka “include”
  • ${CMAKE_INSTALL_DATADIR} aka “share” – not sure what the difference between this and DATAROOTDIR is, but it appears nobody else does either, so I’m just gonna roll with it.

As a side effect, you’ll get a unixy layout on other operating systems too, but as I already was doing this, it’s cool with me.