It didn't say other than "ocio_core_tests". Is there a log that's written I can check? Yeah, I saw the patch but wasn't really sure what it did :) I've setup a version check as part of the process

Cool. Which test is failing? Yah, I looked into switching up to 0.2.7 recently and saw something similar myself. I assume you're not apply the yaml-cpp patch file? The issue is not yaml-cpp 0.2.7

Ok, I've got good news and I've got bad news. I'll start with the good since it's shorter :) Good: - I've gotten a successful build using the yaml-cpp system library. - The current unit test works :)

My preference is to keep using the bundled libs, by default, on all architectures (for the moment). Currently, commercial app developers who want to ship OCIO along side their app (aka Foundry, etc)

<malcolmh...@...> wrote: Hmm... I never tried "hiding" options but I think in this case it would be appropriate. Meaning I'll setup options such as "USE_EXTERNAL_YAMLCPP" and

Yeah that sounds great. I will leave it up to Jeremy to decide what the default is on UNIX. I personally prefer what you are suggesting. As this means if you checkout and build the code what ends up

<malcolmh...@...> wrote: Makes sense, but to make sure I fully understand... Are you saying that even on UNIX systems that bundled libraries should still be used by default and have an option to

I think it's important to support both bundled and unbundled libs. It's a necessary evil inside VFX shop software configurations. So you can use the bundled builds for the APPLE and WIN32 cases and

I already have "make test" in my %check section of my rpmbuild spec file. Is that what you mean? So far I haven't had any test failures in any of my builds. On a side note, unbundling yaml-cpp should

I'll add the additional unit tests related to serialization. But if you could hook the existing unit test process up to the build process, that would be appreciated. The big issue is making sure we

Works for me! I can hack at the unbundling, but I'm probably not going to be much help on the unit tests. What's the approach there? I guess we could come up with as many corner cases we can think

Sure, sounds great. How about 'unbundled'? (not sure how spaces in branch names are handled). -- Jeremy

Hey guys, I was just wondering. Would it be appropriate at this point to setup a branch for "unbundled libs"? That way it could be worked on separately until its ready to merge. Richard

Hi Marie, I also considered integrating OpenColorIO as a set of OFX plugins in my compositor but in the end I decided it was better supporting it directly in my app, so I didn't do much work on the

Hello ! I was considering porting some OpenColorIO Nuke Nodes in OFX to use them in TuttleOFX (among others). It reminds me that this subject was already discussed here (see below). How are things

I just noticed when running rpmlint on my installation of OpenImageIO that PyOpenImageIO can't find a lot of python symbols. I looked in the cmake config for pyglue and noticed that the

Version 1.0.2 (Nov 30 2011): * 3D lut processing (cpu) is resiliant to nans * Nuke OCIOFileTransform gains Reload buttons * Installation on multi-lib *nix systems improved * Installation

Congratulations! -sean

Congrats to the Mari team for Shipping version 1.4v1, which features native OpenColorIO support! http://thefoundry.s3.amazonaws.com/products/mari/releases/1.4v1/Mari_1.4v1_ReleaseNotes.pdf They've

Great! Yeah, I think we can leave the .xcodeproj and .vcproj files out of the main distribution, but I'll keep them in my fork. I'm sure it's possible to reverse engineer the projects into CMake, but