Hi Steve!

OpenEXR does not (and should not) depend on OCIO.

I think I bring the OCIO->OIIO dependency up at every BoF.

What Mark suggests works but is a bit more complicated for shops using an automated build system (OCIO build may succeed but link to the system’s installed OIIO libs instead of the yet-to-be-built ones)  

Build OCIO without ociorender

Build OIIO against OCIO (make sure rpaths do not explicitly point to OCIO build directory)

Build OCIO with ociorender against OIIO

Install OCIO

Install OIIO

OIIO’s dependency on on OCIO is, in my opinion, a necessary thing as it allows OIIO clients to manage color using OCIO.

OCIO’s dependency on OIIO is not essential and should be deprecated (I think its current custodians are in agreement). One of OCIO’s example executables (ociorender?) depends on OIIO for image file IO. This executable can either be

1. moved to a separate package, say OpenColorIOExtensions,
2. made a build option that defaults to off, or better,
3. made to depend on a lightweight image library whose code ships with OCIO (ppm?)
4. dropped altogether from the build, as an installation of OIIO built against OCIO will already have oiiotool, whose functionality overlaps with ociorender.   

-blake