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.