Re: Review: YAML serialization
Jeremy Selan <jeremy...@...>
Addressing the YAML topics:
* I have pushed your commit, plus my non-contentious updates, to spi/yaml. Once build issues are worked out, this will be moved to spi/master (and delete the yaml branch). +1 for GIT. * We are on Cmake 2.8 @ Imageworks, I was just making the observation that your use bumps up the required version from it's prior 2.6 value. * Unfortunately, the compile issue I'm having does not appear to be tied to the namespace stuff. Does your yaml branch currently build? On my linux box, it does not. What OS are you testing on? I tried for about 30 min today to find a fix, but could not figure it out. I still believe the fix is to pass the -fPIC flag to the yaml compilation, but was not able to figure out how to get this passed along. (It's easy to verify though with make VERBOSE=1). I'll look into this more tomorrow. * "The dev on yaml-cpp is pretty active (http://code.google.com/p/yaml-cpp/updates/list) ... If we were choosing to fork yaml-cpp (which I don't think we are) or other ext dependants, checking them in would be fine and would help to indicate a fork. Ok. I'll take the bait. What's the argument against forking our internal dependencies? (I.e., locking off on the known working versions of yaml-cpp, tinyxml, pystring, and md5) If these were all live libraries (.tgz(s) in externals) - something that could be updated easily - people would be inclined to bump up when new versions of the libs are released. And, this feels counter to the "if it aint broke, dont fix it" philosophy. If any of these libraries were exposed in the public headers, it would be a different situation. But seeing as they're all intended to be 100% private, updating them on a semi-frequent basis (or making it easy to do so) probably only has the potential to introduce bugs. Also, even if we do go the .tgz route, we'll need non-trivial .patch files for the namespace adjustments, which makes updating versions not trivial anyways. What new yaml development is being done? I had been presuming that the core library we're considering using is rock solid in both API and implementation. The downside of forking, of course, is that we wouldn't be getting bug fix releases, but when / if we encounter serialization bugs they'll (hopefully) be obvious, and we could then update on an as-needed. Yaml has 64 files, and it took me approx 15 min to namespace it so re-doing that work as needed is not a huge issue. I acknowledge that forking code feels a bit dirty though. For the code voyeurs out there, here's what a fork'd yaml looks like: http://github.com/jeremyselan/OpenColorIO/tree/yaml_fork * http://gcc.gnu.org/wiki/Visibility I hadn't seen this before (on non-windows), but it looks interesting. I like the concept, I'll look into it more. (It will probably have implications with regards to exceptions, but that's arguably a good topic to revisit anyways). -- Jeremy
|
|