A little more news.

I've got USE_EXTERNAL options for setup for LCMS, Yaml-Cpp, and
tinyxml setup in my "bundles" fork.

Currently they are all in a "if(UNIX AND NOT APPLE) conditional so
they only show up on *nix systems, but I'm pretty sure that if someone
added the option it would attempt to use it.

It's currently passing the current tests as long as I'm not using
external Yaml.

Richard

On Fri, Dec 2, 2011 at 3:39 PM, Jeremy Selan <jeremy...@...> wrote:

Which test is failing?

I found the log. Here's the relevant sections:

/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/TruelightTransform.cpp:356:
FAILED: osvec[i] == referenceconfigvec[i]
values were 'search_path: ""' and 'search_path: '
/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/TruelightTransform.cpp:356:
FAILED: osvec[i] == referenceconfigvec[i]
values were 'luma: [0.212599992752075, 0.715200006961823,
0.0722000002861023]' and 'luma: [0.2126, 0.7152, 0.0722]'
/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/TruelightTransform.cpp:356:
FAILED: osvec[i] == referenceconfigvec[i]
values were ' equalitygroup: ""' and ' equalitygroup: '
/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/TruelightTransform.cpp:356:
FAILED: osvec[i] == referenceconfigvec[i]
values were ' equalitygroup: ""' and ' equalitygroup: '
Test [TruelightTransform] [simpletest] - FAILED
---
Why is it testing truelight? I'm not using it..

Another snippet:

/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/Config.cpp:2146:
FAILED: osvec[i] == PROFILE_OUTvec[i]
values were 'search_path: ""' and 'search_path: '
/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/Config.cpp:2146:
FAILED: osvec[i] == PROFILE_OUTvec[i]
values were 'luma: [0.212599992752075, 0.715200006961823,
0.0722000002861023]' and 'luma: [0.2126, 0.7152, 0.0722]'
/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/Config.cpp:2146:
FAILED: osvec[i] == PROFILE_OUTvec[i]
values were ' equalitygroup: ""' and ' equalitygroup: '
/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/Config.cpp:2146:
FAILED: osvec[i] == PROFILE_OUTvec[i]
values were ' - !<FileTransform> {src: "",
interpolation: unknown}' and ' - !<FileTransform> {src: ,
interpolation: unknown}'
/home/build/rpmbuild/OpenColorIO/BUILD/imageworks-OpenColorIO-bfb6b0d/src/core/Config.cpp:2146:
Test [Config_Unit_Tests] [test_ser] - FAILED
FAILED: osvec[i] == PROFILE_OUTvec[i]
values were ' equalitygroup: ""' and ' equalitygroup: '

Richard

On Fri, Dec 2, 2011 at 3:39 PM, Jeremy Selan <jeremy...@...> wrote:

Cool.

Which test is failing?

It didn't say other than "ocio_core_tests". Is there a log that's
written I can check?

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 specific, but rather that in the library both f32 + f64
are serialized with 15 digits of precision.  So we patch yaml to disable the
f64 precision output:

Yeah, I saw the patch but wasn't really sure what it did :)

I've setup a version check as part of the process so when a known good
version is established we can set the version number. Right now it's
hard-coded but I'll setup a cmake macro variable for it.

I contacted the author recently about this. He's in favor of adding
precision controls so we can do this client side, but wont have an
opportunity until this winter break.

http://code.google.com/p/yaml-cpp/issues/detail?id=106

Well, that's hopeful at least. The only question is what to do for
now? I think someone semi-volunteered to ask for a formal exception
from Fedora, otherwise we'll just have to wait.

Thanks,
Richard

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 specific, but rather that in the library both f32 + f64 are serialized with 15 digits of precision.  So we patch yaml to disable the f64 precision output:


--- yaml-cpp-r482/src/emitter.cpp       2011-05-17 16:04:01.794448000 -0700
+++ yaml-cpp-r482/src/emitter.cpp.new   2011-05-17 16:04:25.948733000 -0700
@@ -661,7 +661,7 @@
        {
                PreAtomicWrite();
                EmitSeparationIfNecessary();
-               str.precision(15);
+               // str.precision(15);
        }


I contacted the author recently about this. He's in favor of adding precision controls so we can do this client side, but wont have an opportunity until this winter break.

http://code.google.com/p/yaml-cpp/issues/detail?id=106

-- Jeremy

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 :) See below.

Bad:
- In order to get a good build I have to use yaml-cpp version 0.2.7
which is only available in upcoming Fedora 17.
- The ocio_core_tests fails with stock 0.2.7.

Richard

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) will likely want to build it in this 'self contained' manner to keep distribution as simple as possible.  I'd like to keep life simple for these folks, and make it clear that what they're doing is ok.  The same rules also apply to most of OCIO's current users (large vfx / animation studio) will want to roll it out with binaries that are ABI compatible with commercial releases.

But I'm open to revisiting this in the future, once we get all the new unit tests in place, and can vouch that the unpatched libraries actually produce the same serialization results.

-- Jeremy

On Fri, Dec 2, 2011 at 11:13 AM, Malcolm Humphreys
<malcolmh...@...> wrote:

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 in the binary on all platforms is the same and then treat the
distributions
packaging as an exception to this. But I don't have particularly strong
feelings about it

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 "USE_EXTERNAL_TINYXML" but put them in a
IF(UNIX) conditional so they only appear on *nix system.

Now that I think about it I'll probably have to do it as "IF(UNIX AND
NOT APPLE)" because OSX qualifies an UNIX, right?

Richard

On Fri, Dec 2, 2011 at 8:19 AM, Malcolm Humphreys
<malcolmh...@...> wrote:

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 have this optional in the
unix cases

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 use system libraries mainly for
package maintainers who's distribution do not allow bundled libs?

Thanks,
Richard

On Thu, Dec 1, 2011 at 7:05 PM, Jeremy Selan <jeremy...@...> wrote:

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 dont

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 be pretty easy since it has
a pkg-config file, however, tinyxml doesn't have one or an official
FindTinyXML either. I found one that handled UNIX systems but to be
acceptable I think it should handle APPLE and WIN32 as well, unless we
just want to use the bundled version for windows.

Richard

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 dont have floating-point serialization differences across platform / library.

(Note that we already have one unit test failure on mac related to serialization, I'll look at fixing that at the same time).

-- Jeremy

On Thu, Dec 1, 2011 at 6:49 PM, Jeremy Selan <jeremy...@...> wrote:

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

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 of and make sure they're handled in the same
and or sane manner with different versions/disto versions of the
libraries.

Richard

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

Will do - I'll try and get everything humming along on Windows too, at least with the core tools. I'm hoping I'll have a few days this coming week to tackle this.

cheers

On 11/20/2011 7:44 PM, Jeremy Selan wrote:

Oh - one other dependency consideration I forgot is our use of an
external shared_ptr header.

Currently the default is to look for tr1, and if it's not enabled you
can optionally specify boost. What should the standard installation do?
Maybe on linux / osx, we always assume the existence of tr1? How about
on windows?

I'm not sure you can assume tr1 on Windows. It first showed up in VS2008 SP1, but some people (including us) aren't using SP1, for compatibility reasons with certain runtimes. However, if you need tr1 you can get it from boost (which is what we do). I have no problem with requiring boost, though I can see it being quite the pain for people who aren't yet using it on Windows. A catch 22 if I ever saw one. Maybe you should just assume people have tr1 afterall. :-)

Oh - one other dependency consideration I forgot is our use of an external shared_ptr header.

On Sun, Nov 20, 2011 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:

- Richard.  Any thoughts on how we can make the unit tests part of the
installation / build process?

On the RPM side (including Suse and other RPM systems), it's easy. The
spec file supports a %check section and a failure in this area
(non-zero exit) will fail the build. I'm sure Debian based systems
have an equivalent.

Richard

So i've learned a lot about packaging these last few days!  Who knew there was so much to it? ;)