Hmmm, that patch doesnt quite work for us locally at Imageworks. (I
think it's probably because we use a namespaced version of boost, and
the macro isn't quite right in our context). Let me see if I can find
a solution that works for both of us.

I've also been rethinking the use of boost within OCIO. Currently
there are only two things we use it for: shared_ptr and the unit test
framework. Given the issues that can occur when linking against
other apps the rely on different boost versions, boost may be a can of
worms worth avoiding, particularly considering that at this time it
may be a pretty simple dependency to remove.

Does anyone have any strong feelings (or experience) on this?

-- Jeremy

Hi Jeremy,

On Mon, Sep 20, 2010 at 4:10 PM, Jeremy Selan <jeremy...@...> wrote:

I've also been rethinking the use of boost within OCIO.  Currently
there are only two things we use it for: shared_ptr and the unit test
framework.

shared_ptr is header only and you're already using CMake, so perhaps
it'd be worth
looking at using CMake's unit testing instead of boost's?

This way there's no linking dependencies against boost.

Cheers,

Alan.

Actually, I dont believe there currently is a link dependency to boost.

ldd src/core/libOpenColorIO.so :

linux-vdso.so.1 => (0x00007fff63afb000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4b3241a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4b32196000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f4b31f80000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4b31c30000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4b329e5000)

And, a bit surprisingly, even the unit test program doesnt appear to
link to boost:
ldd src/core/ocio_core_tests:

linux-vdso.so.1 => (0x00007fff09fb8000)
libOpenColorIO.so => libOpenColorIO.so (0x00007f41d812d000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f41d7e1f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f41d7b9c000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f41d7986000)
libc.so.6 => /lib64/libc.so.6 (0x00007f41d7636000)
/lib64/ld-linux-x86-64.so.2 (0x00007f41d83b3000)


So the only benefit would be to remove it as a compile time dependency
(presuming that we dont let anyone use at link time, either).

-- Jeremy

Hi Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@...> wrote:

Actually, I dont believe there currently is a link dependency to boost.

Ahhh, my bad. In quick reading up on it I'd assumed that they were
referring to linking
with boost's libraries, rather than the test modules created within
the user's code.

I did a little more reading here
http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/utf/user-guide/usage-variants/dynamic-lib-variant.html

It seems that BOOST_TEST_DYN_LINK can be specified in Makefiles instead. Perhaps
there's some logic that can be dropped into the CMakeLists.txt to
handle this transparently?

Cheers,

Alan.

Ok, so I just checked in a bunch of changes to the unit testing (spi
github repository). These changes may or may not affect the build
error you've gotten. I'll check your error on OSX when I get home
tonight, my hope is that i'll be able to re-create your error there).

Previously, the unit tests were in their own .cpp files, interleaved
within the src/core directory. This had the advantage of simplicity,
but one major disadvantage that anything that wanted to be unit tested
had to be available in an include. Being a major fan of anonymous
namespaces, and really prefering to keep as much as possible in .cpp
files (rather than .h files), this wasn't ideal.

In this new unittest approach we build src/core twice. Once normally,
and then again with an additional #define, OCIO_UNIT_TEST. (This is
controlled through the src/core_tests submodule).

The upside is we can build the core library without including boost symbols:

nm -C lib/libOpenColorIO.so | grep unit | wc -l

0

and then build the test library including boost testing, as a
build-time dependency

nm -C bin/ocio_core_tests | grep unit | wc -l

1430

I also really like that you can easily nit test small helper functions
that do not escape the file.

For an example of this in practice see
src/core/FileFormatCSP.cpp

The downsides are the the build process (for core) is twice as long,
and that the implementation files may get longer. But I think it's
worth it to keep the code and associated tests together.

Thoughts?

-- Jeremy


On Mon, Sep 20, 2010 at 3:19 PM, Alan Jones <sky...@...> wrote:

Hi Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@...> wrote:

Actually, I dont believe there currently is a link dependency to boost.

Ahhh, my bad. In quick reading up on it I'd assumed that they were
referring to linking
with boost's libraries, rather than the test modules created within
the user's code.

I did a little more reading here
http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/utf/user-guide/usage-variants/dynamic-lib-variant.html

It seems that BOOST_TEST_DYN_LINK can be specified in Makefiles instead. Perhaps
there's some logic that can be dropped into the CMakeLists.txt to
handle this transparently?

Cheers,

Alan.

The downsides are the the build process (for core) is twice as long,
and that the implementation files may get longer. But I think it's
worth it to keep the code and associated tests together.

Thoughts?

I think thats fine, the DEBUG/TEST build would build both and the RELEASE wouldn't.

.malcolm

-- Jeremy


On Mon, Sep 20, 2010 at 3:19 PM, Alan Jones <sky...@...> wrote:

Hi Jeremy,

On Mon, Sep 20, 2010 at 5:09 PM, Jeremy Selan <jeremy...@...> wrote:

Actually, I dont believe there currently is a link dependency to boost.

Ahhh, my bad. In quick reading up on it I'd assumed that they were
referring to linking
with boost's libraries, rather than the test modules created within
the user's code.

I did a little more reading here
http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/utf/user-guide/usage-variants/dynamic-lib-variant.html

It seems that BOOST_TEST_DYN_LINK can be specified in Makefiles instead. Perhaps
there's some logic that can be dropped into the CMakeLists.txt to
handle this transparently?

Cheers,

Alan.