Date   

Re: Setting OIIO_NAMESPACE

Jeremy Selan <jeremy...@...>
 

Should should not need to set OIIO_NAMESPACE.  Even when you build oiio with a custom namespace,   OIIO_NAMESPACE is a macro that get's baked into the oiio installation.

I've confirmed this works at SPI.  For example, we build ociodisplay and only specify the following...

-D OCIO_BUILD_APPS=YES \
-D OIIO_LIBRARY_PATH=$OIIO_SPCOMP2_LIBDIR \
-D OIIO_INCLUDE_PATH=$OIIO_SPCOMP2_INCLUDEDIR \

Where in OIIO_INCLUDE_PATH, there is version.h, which includes:

#define OIIO_NAMESPACE OpenImageIO_SPI

What's inside your version.h for the OIIO installation?  Does it match the namespace you see for the real symbols for your oiio so? (nm -C -D)

-- Jeremy





On Fri, Dec 9, 2011 at 9:44 AM, Jeff Clifford <j...@...> wrote:
Hi,

It's not setting OCIO_NAMESPACE that is the problem.

It's the need to set OIIO_NAMESPACE - i.e. the OpenImageIO requirement for the apps.  Is there a way to set that - I've tried setting it but it doesn't seem to get passed on.

Thanks,

Jeff.


Malcolm Humphreys wrote:
Hi Jeff,

This gets set line 69 in the main CMakeList.txt file to 'OpenColorIO' if the cmake var OCIO_NAMESPACE is not set.

--snip--
# Set the default namespace
if(NOT OCIO_NAMESPACE)
  set(OCIO_NAMESPACE OpenColorIO CACHE STRING
      "Specify the master OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc."
      FORCE)
endif(NOT OCIO_NAMESPACE)
messageonce("Setting Namespace to: ${OCIO_NAMESPACE}")
--snip--

Have you tried from a clean build dir? cmake sometimes has problems if something went wrong on a previous run When it does work you should be able to control this like so 'cmake -DOCIO_NAMESPACE=OCIODNEG ...' flag.

Also which version of cmake are you using? and during the cmake run what does ''Setting Namespace to: XXX" say.

.malcolm

On 10 Dec, 2011,at 03:11 AM, Jeff Clifford <...@...> wrote:

Hi,

When building the apps that come with OpenColorIO I hit the following errors (under gcc):

[EE] /user_data/ARCHIVE/imageworks-OpenColorIO-de86248/src/apps/ocioconvert/main.cpp:37: error: 'OIIO_NAMESPACE' is not a namespace-name

which is fair enough as indeed I haven't defined it.

Is there a proper way to do this with OpenColorIO - the only way I've managed to set it is by appending

     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DOIIO_NAMESPACE=OpenImageIO -Wall -Wextra -Wshadow -Wconversion -Wcast-qual -Wformat=2")

it into CMakeListstxt

I would have thought that this define should be set as the default unless overridden by the user with something like

set(OIIO_NAMESPACE "OpenImageIO")

But that has no affect.

Thanks,

Jeff.

P.S.  Trying to set the define on the command line doesn't work either - i.e. with CMAKE_CXX_FLAGS="-DOIIO_NAMESPACE=OpenImageIO"

I end up with this entry in CMakeCache.txt:

CMAKE_CXX_FLAGS=-DOIIO_NAMESPACE:UNINITIALIZED=OpenImageIO

rather than it being added to

CMAKE_CXX_FLAGS:STRING=

- I think this is more my lack of understanding of adding definitions to cmake correctly!


Re: Building issues with gcc

Jeremy Selan <jeremy...@...>
 

Committed.

-- Jeremy


On Fri, Dec 9, 2011 at 6:49 AM, Jeff Clifford <j...@...> wrote:
Yep good for me now too thanks.  Both gcc412 and gcc433 build fine and using -D CMAKE_CXX_FLAGS= passes through too.


Richard Shaw wrote:
On Thu, Dec 8, 2011 at 8:06 PM, Jeremy Selan <jere...@...> wrote:
  
I pushed a fix to my local master that detects what gcc is being used, and
acts accordingly.

Would you test with both of your gcc versions and confirm this works?  I
wasn't sure if -fPIC should still be used on gcc4.1, so I left it on
(current behavior).

diff:
https://github.com/jeremyselan/OpenColorIO/commit/f0f45901178462287b713de1d9c51e0fc517ab47

Download the updated CMakeLists.txt:
https://raw.github.com/jeremyselan/OpenColorIO/f0f45901178462287b713de1d9c51e0fc517ab47/CMakeLists.txt
    
Built with no errors on my system (GCC 4.6.1)

Richard
  


Re: Setting OIIO_NAMESPACE

Jeff Clifford <j...@...>
 

Hi,

It's not setting OCIO_NAMESPACE that is the problem.

It's the need to set OIIO_NAMESPACE - i.e. the OpenImageIO requirement for the apps.  Is there a way to set that - I've tried setting it but it doesn't seem to get passed on.

Thanks,

Jeff.

Malcolm Humphreys wrote:

Hi Jeff,

This gets set line 69 in the main CMakeList.txt file to 'OpenColorIO' if the cmake var OCIO_NAMESPACE is not set.

--snip--
# Set the default namespace
if(NOT OCIO_NAMESPACE)
  set(OCIO_NAMESPACE OpenColorIO CACHE STRING
      "Specify the master OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc."
      FORCE)
endif(NOT OCIO_NAMESPACE)
messageonce("Setting Namespace to: ${OCIO_NAMESPACE}")
--snip--

Have you tried from a clean build dir? cmake sometimes has problems if something went wrong on a previous run When it does work you should be able to control this like so 'cmake -DOCIO_NAMESPACE=OCIODNEG ...' flag.

Also which version of cmake are you using? and during the cmake run what does ''Setting Namespace to: XXX" say.

.malcolm

On 10 Dec, 2011,at 03:11 AM, Jeff Clifford <...@...> wrote:

Hi,

When building the apps that come with OpenColorIO I hit the following errors (under gcc):

[EE] /user_data/ARCHIVE/imageworks-OpenColorIO-de86248/src/apps/ocioconvert/main.cpp:37: error: 'OIIO_NAMESPACE' is not a namespace-name

which is fair enough as indeed I haven't defined it.

Is there a proper way to do this with OpenColorIO - the only way I've managed to set it is by appending

     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DOIIO_NAMESPACE=OpenImageIO -Wall -Wextra -Wshadow -Wconversion -Wcast-qual -Wformat=2")

it into CMakeListstxt

I would have thought that this define should be set as the default unless overridden by the user with something like

set(OIIO_NAMESPACE "OpenImageIO")

But that has no affect.

Thanks,

Jeff.

P.S.  Trying to set the define on the command line doesn't work either - i.e. with CMAKE_CXX_FLAGS="-DOIIO_NAMESPACE=OpenImageIO"

I end up with this entry in CMakeCache.txt:

CMAKE_CXX_FLAGS=-DOIIO_NAMESPACE:UNINITIALIZED=OpenImageIO

rather than it being added to

CMAKE_CXX_FLAGS:STRING=

- I think this is more my lack of understanding of adding definitions to cmake correctly!


Re: Setting OIIO_NAMESPACE

Malcolm Humphreys <malcolmh...@...>
 

Hi Jeff,

This gets set line 69 in the main CMakeList.txt file to 'OpenColorIO' if the cmake var OCIO_NAMESPACE is not set.

--snip--
# Set the default namespace
if(NOT OCIO_NAMESPACE)
  set(OCIO_NAMESPACE OpenColorIO CACHE STRING
      "Specify the master OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc."
      FORCE)
endif(NOT OCIO_NAMESPACE)
messageonce("Setting Namespace to: ${OCIO_NAMESPACE}")
--snip--

Have you tried from a clean build dir? cmake sometimes has problems if something went wrong on a previous run When it does work you should be able to control this like so 'cmake -DOCIO_NAMESPACE=OCIODNEG ...' flag.

Also which version of cmake are you using? and during the cmake run what does ''Setting Namespace to: XXX" say.

.malcolm

On 10 Dec, 2011,at 03:11 AM, Jeff Clifford <...@...> wrote:

Hi,

When building the apps that come with OpenColorIO I hit the following errors (under gcc):

[EE] /user_data/ARCHIVE/imageworks-OpenColorIO-de86248/src/apps/ocioconvert/main.cpp:37: error: 'OIIO_NAMESPACE' is not a namespace-name

which is fair enough as indeed I haven't defined it.

Is there a proper way to do this with OpenColorIO - the only way I've managed to set it is by appending

     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DOIIO_NAMESPACE=OpenImageIO -Wall -Wextra -Wshadow -Wconversion -Wcast-qual -Wformat=2")

it into CMakeListstxt

I would have thought that this define should be set as the default unless overridden by the user with something like

set(OIIO_NAMESPACE "OpenImageIO")

But that has no affect.

Thanks,

Jeff.

P.S.  Trying to set the define on the command line doesn't work either - i.e. with CMAKE_CXX_FLAGS="-DOIIO_NAMESPACE=OpenImageIO"

I end up with this entry in CMakeCache.txt:

CMAKE_CXX_FLAGS=-DOIIO_NAMESPACE:UNINITIALIZED=OpenImageIO

rather than it being added to

CMAKE_CXX_FLAGS:STRING=

- I think this is more my lack of understanding of adding definitions to cmake correctly!


Setting OIIO_NAMESPACE

Jeff Clifford <j...@...>
 

Hi,

When building the apps that come with OpenColorIO I hit the following errors (under gcc):

[EE] /user_data/ARCHIVE/imageworks-OpenColorIO-de86248/src/apps/ocioconvert/main.cpp:37: error: 'OIIO_NAMESPACE' is not a namespace-name

which is fair enough as indeed I haven't defined it.

Is there a proper way to do this with OpenColorIO - the only way I've managed to set it is by appending

     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DOIIO_NAMESPACE=OpenImageIO -Wall -Wextra -Wshadow -Wconversion -Wcast-qual -Wformat=2")

it into CMakeLists.txt

I would have thought that this define should be set as the default unless overridden by the user with something like

set(OIIO_NAMESPACE "OpenImageIO")

But that has no affect.

Thanks,

Jeff.

P.S.  Trying to set the define on the command line doesn't work either - i.e. with CMAKE_CXX_FLAGS="-DOIIO_NAMESPACE=OpenImageIO"

I end up with this entry in CMakeCache.txt:

CMAKE_CXX_FLAGS=-DOIIO_NAMESPACE:UNINITIALIZED=OpenImageIO

rather than it being added to

CMAKE_CXX_FLAGS:STRING=

- I think this is more my lack of understanding of adding definitions to cmake correctly!


Re: Building issues with gcc

Jeff Clifford <j...@...>
 

Yep good for me now too thanks.  Both gcc412 and gcc433 build fine and using -D CMAKE_CXX_FLAGS= passes through too.

Richard Shaw wrote:

On Thu, Dec 8, 2011 at 8:06 PM, Jeremy Selan <jere...@...> wrote:
  
I pushed a fix to my local master that detects what gcc is being used, and
acts accordingly.

Would you test with both of your gcc versions and confirm this works?  I
wasn't sure if -fPIC should still be used on gcc4.1, so I left it on
(current behavior).

diff:
https://github.com/jeremyselan/OpenColorIO/commit/f0f45901178462287b713de1d9c51e0fc517ab47

Download the updated CMakeLists.txt:
https://raw.github.com/jeremyselan/OpenColorIO/f0f45901178462287b713de1d9c51e0fc517ab47/CMakeLists.txt
    
Built with no errors on my system (GCC 4.6.1)

Richard
  


Re: Building issues with gcc

Richard Shaw <hobbe...@...>
 

On Thu, Dec 8, 2011 at 8:06 PM, Jeremy Selan <jeremy...@...> wrote:
I pushed a fix to my local master that detects what gcc is being used, and
acts accordingly.

Would you test with both of your gcc versions and confirm this works?  I
wasn't sure if -fPIC should still be used on gcc4.1, so I left it on
(current behavior).

diff:
https://github.com/jeremyselan/OpenColorIO/commit/f0f45901178462287b713de1d9c51e0fc517ab47

Download the updated CMakeLists.txt:
https://raw.github.com/jeremyselan/OpenColorIO/f0f45901178462287b713de1d9c51e0fc517ab47/CMakeLists.txt
Built with no errors on my system (GCC 4.6.1)

Richard


Re: Building issues with gcc

Jeremy Selan <jeremy...@...>
 

I pushed a fix to my local master that detects what gcc is being used, and acts accordingly.

Would you test with both of your gcc versions and confirm this works?  I wasn't sure if -fPIC should still be used on gcc4.1, so I left it on (current behavior).

diff:
https://github.com/jeremyselan/OpenColorIO/commit/f0f45901178462287b713de1d9c51e0fc517ab47

Download the updated CMakeLists.txt:
https://raw.github.com/jeremyselan/OpenColorIO/f0f45901178462287b713de1d9c51e0fc517ab47/CMakeLists.txt

-- Jeremy


On Thu, Dec 8, 2011 at 12:27 PM, Jeff Clifford <j...@...> wrote:
Hi Jeremy,

Thanks for getting back to me so fast.

I can confirm already that omitting the -fvisibility-inlines-hidden from just CMakeLists.txt works.

I can also confirm that the issue doesn't occur for our gcc4.3.3 build - only for our gcc4.1.2 build.

Thanks,

Jeff.


Re: Building issues with gcc

Jeff Clifford <j...@...>
 

Hi Jeremy,

Thanks for getting back to me so fast.

I can confirm already that omitting the -fvisibility-inlines-hidden from just CMakeLists.txt works.

I can also confirm that the issue doesn't occur for our gcc4.3.3 build - only for our gcc4.1.2 build.

Thanks,

Jeff.

Jeremy Selan wrote:

I've pushed the fix for CMAKE_CXX_FLAGS to master. Thanks for pointing that out.

As for -fvisibility-inlines-hidden, the only places that appears in OCIO are:
CMakeLists.txt
ext/tinyxml_2_6_1.patch
ext/yaml-cpp-r482.patch

Would you try commenting out the offending lines, and see if that can build on your gcc version?

There are currently checks for CMAKE_COMPILER_IS_GNUCXX around these lines, and if we can confirm that older gccs dont support this option I'm happy to add an additional gcc version check as well.

-- Jeremy

On Thu, Dec 8, 2011 at 8:57 AM, Jeremy Selan <jeremy...@... <mailto:jeremy...@...>> wrote:

I'll hold off on commenting on the first issue for the moment, but
the 2nd issue (not preserving incoming CMAKE_CXX_FLAGS) is clearly
an oversight. I'll check in a fix today.

-- Jeremy


------------------------------------------------------------------------

No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 10.0.1415 / Virus Database: 2102/4067 - Release Date: 12/08/11


Re: Building issues with gcc

Jeremy Selan <jeremy...@...>
 

I've pushed the fix for CMAKE_CXX_FLAGS to master. Thanks for pointing that out.

As for
-fvisibility-inlines-hidden, the only places that appears in OCIO are:
CMakeLists.txt
ext/tinyxml_2_6_1.patch
ext/yaml-cpp-r482.patch

Would you try commenting out the offending lines, and see if that can build on your gcc version?

There are currently checks for CMAKE_COMPILER_IS_GNUCXX around these lines, and if we can confirm that older gccs dont support this option I'm happy to add an additional gcc version check as well.

-- Jeremy


On Thu, Dec 8, 2011 at 8:57 AM, Jeremy Selan <jeremy...@...> wrote:
I'll hold off on commenting on the first issue for the moment, but the 2nd issue (not preserving incoming CMAKE_CXX_FLAGS) is clearly an oversight.  I'll check in a fix today.

-- Jeremy


Re: Building issues with gcc

Jeremy Selan <jeremy...@...>
 

I'll hold off on commenting on the first issue for the moment, but the 2nd issue (not preserving incoming CMAKE_CXX_FLAGS) is clearly an oversight.  I'll check in a fix today.

-- Jeremy


Re: Building issues with gcc

Richard Shaw <hobbe...@...>
 

On Thu, Dec 8, 2011 at 9:28 AM, Jeff Clifford <j...@...> wrote:
Hi,

I've hit upon a couple of issues when trying to build the core OpenColorIO
lib.

a)

The following error occurs:

/usr/bin/ld: CMakeFiles/OpenColorIO.dir/Baker.cpp.o: relocation
R_X86_64_PC32 against `std::basic_ostringstream<char,
std::char_traits<char>, std::allocator<char>
::basic_ostringstream(std::_Ios_Openmode)@@GLIBCXX_3.4' can not be used
when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [src/core/libOpenColorIO.so.1.0.2] Error 1
Disclaimer: I'm not a programmer :)

But, I do know that Fedora builds with -fPIC by default, which the
error message suggests. I haven't run into this issue with Fedora 15
which uses a pretty recent gcc version.

Richard


Building issues with gcc

Jeff Clifford <j...@...>
 

Hi,

I've hit upon a couple of issues when trying to build the core OpenColorIO lib.

a)

The following error occurs:

/usr/bin/ld: CMakeFiles/OpenColorIO.dir/Baker.cpp.o: relocation R_X86_64_PC32 against `std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode)@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [src/core/libOpenColorIO.so.1.0.2] Error 1

I believe this is a known error for certain versions of gcc because OpenColorIO uses the -fvisibility-inlines-hidden flag by default (disable this flag and the error goes away).

FYI my compile line for Baker.cpp was:

cd /user_data/ARCHIVE/ociobuild/src/core && /tools/SITE/rnd/scripts/g++412   -DOpenColorIO_EXPORTS -DUSE_SSE -Wall -Wextra -Wshadow -Wconversion -Wcast-qual -Wformat=2 -L/apps/Linux64/gcc/gcc412/lib64 -msse2 -O2 -g -fPIC -I/user_data/ARCHIVE/imageworks-OpenColorIO-de86248/export -I/user_data/ARCHIVE/ociobuild/export -I/user_data/ARCHIVE/ociobuild/ext/dist/include -I/user_data/ARCHIVE/imageworks-OpenColorIO-de86248/ext/oiio/src/include   -DTIXML_USE_STL -fPIC -fvisibility-inlines-hidden -fvisibility=hidden -o CMakeFiles/OpenColorIO.dir/Baker.cpp.o -c /user_data/ARCHIVE/imageworks-OpenColorIO-de86248/src/core/Baker.cpp

b)

If you need to build OpenColorIO with a centrally installed version of gcc (like we do at DNeg) rather than the default local machine's one then currently passing the required CXX_FLAGS using -D CMAKE_CXX_FLAGS="-L/apps/Linux64/gcc/gcc412/lib64" as a cmake command line argument doesn't work.

The CMakeLists.txt file is overriding any options here:

if(CMAKE_COMPILER_IS_GNUCXX)
    # Enable a bunch of compiler warnings...
    # http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
    set(CMAKE_CXX_FLAGS "-Wall -Wextra -Wshadow -Wconversion -Wcast-qual -Wformat=2")
    # set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pedantic")
endif(CMAKE_COMPILER_IS_GNUCXX)

rather than appending to the builder's options.

Regards,

Jeff.



Re: Handling of bundled apps/libraries for Linux distro packaging.

Richard Shaw <hobbe...@...>
 

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


Re: Handling of bundled apps/libraries for Linux distro packaging.

Richard Shaw <hobbe...@...>
 

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


Re: Handling of bundled apps/libraries for Linux distro packaging.

Richard Shaw <hobbe...@...>
 

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


Re: Handling of bundled apps/libraries for Linux distro packaging.

Jeremy Selan <jeremy...@...>
 

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


On Fri, Dec 2, 2011 at 1:29 PM, Richard Shaw <hobbe...@...> wrote:
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


Re: Handling of bundled apps/libraries for Linux distro packaging.

Richard Shaw <hobbe...@...>
 

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


Re: Handling of bundled apps/libraries for Linux distro packaging.

Jeremy Selan <jeremy...@...>
 

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 9:13 AM, Malcolm Humphreys <malcolmh...@...> wrote:
On 03 Dec, 2011,at 01:35 AM, Richard Shaw <hobbe...@...> wrote:

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?
 
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

.malcolm




Re: Handling of bundled apps/libraries for Linux distro packaging.

Richard Shaw <hobbe...@...>
 

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

1501 - 1520 of 2227