Compiling for Windows 7, VS2010

Jeremy Selan <jeremy...@...>

My apologies that compilation is not easier on windows.

Our choice to use an external shared_ptr, in retrospect, makes portability more challenging than it need be; this is one of our top priorities to address next year.  Along these lines, distributing OCIO precompiled binaries as 'system installs' is one of my major goals for next year.  This would take a huge step forwards for allowing people to upgrade their OCIO system library version to alleviate apps that ship with older library versions.

Currently in our CMake install, it appears we DO require the use of boost on windows for access to ptr:

# Use boost's shared_ptr by default on Windows (as <VS2010 doesn't have it),
# Use std::tr1::shared_ptr by default on other platforms
option(OCIO_USE_BOOST_PTR "Set to ON to enable boost shared_ptr (necessary when tr1 is not available)" WIN32)

However, reading the docs online it's pretty clear that both VS2010 and 2012 DO include a ptr:

So you have two options to try:
- install boost, and then compile with OCIO_USE_BOOST_PTR 1
- dont install boost, and path the OpenColorABI.h to define the ptr from the proper location

(in this case, the code would look something like...

#include <boost/shared_ptr.hpp>
#define OCIO_SHARED_PTR boost::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST boost::dynamic_pointer_cast

#elif __GNUC__ >= 4
#include <tr1/memory>
#define OCIO_SHARED_PTR std::tr1::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::tr1::dynamic_pointer_cast

#elif (_MSC_VER > 1600)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

#error OCIO needs gcc 4 or later to get access to <tr1/memory> (or specify USE_BOOST_PTR instead)

-- Jeremy

On Wed, Nov 7, 2012 at 11:22 AM, Andrew Britton <cbsd....@...> wrote:
Good afternoon,

First let me say that I'm very grateful for the efforts of all involved in making OCIO come to be.

I'm currently attempting to compile OCIO for Win7 and am having a difficult time finding a best practices document outlining this process. It should be said, and for this I apologize in advance, that I am not well experienced with compilers or the science of compiling. I'm just a coder trying to get OCIO built so I can start turning LUTs into ICC profiles and ACES into all other magical concoctions.
Currently, I'm found the documentation regarding cmake and have installed that.

So my steps, to date, are as follows:
given: (I already have VS2010 installed)
  • install CMAKE (I'm currently running 2.8)
  • From this resource, make these directories:
    • software/ocio = C:\Program Files (x86)\ocio
    • source/ocio = E:\Tools\Research\OpenColorIO\SourceCode\imageworks-OpenColorIO-v1.0.7-17-g533f85e\imageworks-OpenColorIO-533f85e
    • tmp/ociobuild = E:\Tools\Research\OpenColorIO\SourceCode\tmp\ociobuild
  • I then run cmake from a cmd.exe window (running as administrator, and when not running as administrator)
    • cmake -D CMAKE_INSTALL_PREFIX="C:\Program Files (x86)\ocio" -G "NMake Makefiles" E:\Tools\Research\OpenColorIO\SourceCode\imageworks-OpenColorIO-v1.0.7-17-g533f85e\imageworks-OpenColorIO-533f85e > cmake_results.txt
  • And then things get a little hairy.
    • First, no files appear in "C:\Program Files (x86)\ocio"
    • This is the result of the cmake_results.txt

-- The C compiler identification is MSVC 16.0.30319.1
-- The CXX compiler identification is MSVC 16.0.30319.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Setting Build Type to: Debug
-- Setting Namespace to: OpenColorIO
-- Exec prefix not specified, defaulting to C:/Program Files (x86)/ocio
-- Use Boost Ptr: OFF
-- Generate Documentation: OFF
-- SSE Optimizations: ON
-- Could NOT find Truelight (missing:  Truelight_INCLUDE_DIR Truelight_LIBRARIES Truelight_LIBRARY_DIR)
-- Not building truelight transform support. Add the flag -D TRUELIGHT_INSTALL_PATH=... or set the TRUELIGHT_ROOT environment variable
-- Create OpenColorABI.h from
-- Setting OCIO SOVERSION to: 1
-- Setting OCIO SOVERSION to: 1
-- Create OpenColorIO.pc from
-- Build Unit Tests: OFF
-- OIIO not found. Specify OIIO_PATH to locate it
-- Not building ocioconvert/ociolutimage. Requirement(s) found: OIIO:FALSE
-- Found OpenGL: opengl32 
-- Found OpenGL library glu32;opengl32
-- Found OpenGL includes
-- Could NOT find GLUT (missing:  GLUT_glut_LIBRARY GLUT_INCLUDE_DIR)
-- GLUT not found
-- GLEW not found
-- Not building ociodisplay. Requirement(s) found, OpenGL:TRUE, GLUT:FALSE, GLEW:FALSE, OIIO:FALSE
-- Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE)
-- Using bundled lcms.
-- Could NOT find Nuke (missing:  Nuke_INCLUDE_DIR Nuke_LIBRARIES Nuke_LIBRARY_DIR)
-- Not building Nuke plugins. Add the flag -D NUKE_INSTALL_PATH=... or set the NDK_PATH environment variable
-- Python bindings will not be built:
-- Configuring done
-- Generating done
-- Build files have been written to: E:/Tools/Research/OpenColorIO/SourceCode/tmp/ociobuild

I understand that the applications are building and that the Python bindings aren't as well. This is not a problem.

Possible areas of trouble:
  • I don't have Boost installed, BUT I am running VS2010. Do I still need to install Boost?
  • I didn't set the build to be a "release" build

Alternate attempt:

I've also tried compiling this from VS2010 by starting with cmake. This time though I use this cmake call:

  • cmake -D CMAKE_INSTALL_PREFIX="C:\Program Files (x86)\ocio" E:\Tools\Research\OpenColorIO\SourceCode\imageworks-OpenColorIO-v1.0.7-17-g533f85e\imageworks-OpenColorIO-533f85e -G "Visual Studio 10 Win64" > cmake_results.txt
    • I get the same result if I do not specify a makefile generator with the "-G" flag (except that the .sln file is built for win32)
This creates a series of VS2010 projects and a single solution (.sln) file in the \tmp\ociobuild directory. I open the OpenColorIO.sln file. So I open the .sln and build ALL_BUILD. The first error I receive is that Patch.exe has unexpectedly quit. It took me a while to track down exactly what "patch.exe" was. It's the Perl patch function installed with my "strawberry" flavor of Perl.
So my next question is:
Q: Is there a specific flavor or version of Perl for the windows environment to properly build OCIO?

Lastly, I keep getting multiple errors about OCIO needing gcc 4 or later to get access to <tr1/memory> and it suggests that instead I should specify USE_BOOST_PTR. So, it looks like I should install Boost and recompile.

I know I'm going to have more questions so I'll end this here and keep investigating.

Thank you