Ok, so there is a initial go at this in the other mail. I have added a local copy of yaml-cpp and a patch to make it build static. Once we get a little further down the road, we can work with the

- Initial checkin of YAML serialization - Added ext/yaml-cpp-0.2.5.tar.gz with a patch to build it static - Added yaml-cpp to the LICENCE file - CDLTransform should be the only thing depending on

Hi All, Just wanted to throw a quick thought in on C++ LUTs. I've recently been dealing with Arri's Alexa. One of the more unusual aspects of it's Log-C transform is that it changes based on

Ok, I'm convinced. Let's give YAML a shot. In terms of broad technical strokes, I think either YAML or XML would be sufficient. But given your enthusiasm for YAML, and it's superior human

Hi Jeremy, You can use the CPACK_SOURCE_IGNORE_FILES to hold a semi-colon separated list of regexs to ignore files/directories. Cheers, Alan.

There is a cpack ignore dirs command, I would recommended doing out of source builds also. "Jeremy Selan" <jeremy...@...> wrote: -- Sent from my phone.

One gotcha: when you use `make package_source` it appears to grab all files in the subdirectory, including the build dirs and other files which may not be part of the repository. I'm looking at

looks good to me. -- Jeremy <malcolmh...@...> wrote:

* added cpack support to replace the tgz_create script. Run 'make package_source' to create 'olio.VERSION.tar.gz' * removed tgz_create

LGTM - even without any tests : ) .malcolm

Ok lets jump in :) There are a few good articles on the subject of choosing XML 'just because', these two I

The ExponentTransform (a publicly exposed class for doing power / gamma operations) previously could not serialize itself to xml. This commit adds the

Sorry I will be responding to this soon, bit busy for the next 3 days. .malcolm

http://code.google.com/p/yaml-cpp/ ...is the compiled yaml io library. I believe yaml support is built into the python distro. -blake

I'm completely in favor of making the OCIO configuration files easier to read and edit. I have a few specific concerns about YAML, but it's definitely worth exploring. Care to take a stab at it? In

I'm happy to match what ever style you put forward, I mainly like doing this as it makes it really clear what a function / method is returning. We don't have function overloading but in code bases

Looks good to me! I really like the VERSION consolidation and the cmake "configure_file" mojo. Now that I know about that approach, I'll use it for the OCIO_NAMESPACE #define as well... -- Jeremy

Also - for future reference - you don't need to include the patch file. It will be sufficient to just include the SHA1 hash for the top- most commit that corresponds to the topic. For example, in

Looks good to me! I have a few comments, but these dont need to be addressed yet. * In terms of coding style, you put the return value on a new line, where as I tend to not. I'm actually fine

I wanted some pkgconfig (http://en.wikipedia.org/wiki/Pkg-config) support to make it easier to build against OCIO. Part of this needed burning the ocio version into the .pc file, so I rejigged things