Static library does not contain YAML, TinyXML symbols

[nrusch]

GCC 4.8.3 on Fedora 19

Currently, the build process for the static OCIO library does not include the tinyxml and yaml-cpp objects when the bundled dependencies are used, so it is effectively DOA when used in another project due to missing symbols, unless that project also links those two dependencies (which OCIO doesn't "install") into their binary. I'm not sure if this is due to a regression or bug in the OCIO CMake scripts, but from what I've found, there doesn't appear to be a way to get CMake to link one static library into another by copying the objects from the dependency into the target.

If that is in fact the case, and if it's acceptable to require at least CMake 2.8.8, I think the simplest solution to this problem would be building those two dependencies to target the OBJECT library type (instead of STATIC), as documented here. I think the final OCIO library targets (I believe this approach would work for the shared library as well) would then need to be changed to look roughly like this:

add_library(OpenColorIO_STATIC STATIC
    ${core_src_files}
    $<TARGET_OBJECTS:tinyxml>
    $<TARGET_OBJECTS:YAML_CPP_LOCAL>)

If the CMake minimum version requirement is deemed too restricting, this may require the use of a custom target that uses COMMAND ${CMAKE_CXX_ARCHIVE_CREATE} to archive all of the necessary objects.

[scoopxyz]

Should be addressed by #453

[nrusch]

Closing, as this does seem to be fixed now.

[nrusch]

Nevermind, the static library is still missing the symbols from the YAML and TinyXML libraries.

[roelandschoukens]

You can enable YAML_CPP_OBJECT_LIB_EMBEDDED and TINYXML_OBJECT_LIB_EMBEDDED to embed the libraries in OpenColorIO.lib.

With those macros Off, I would guess the expected behaviour is that the yaml and tinyxml libraries are installed alongside OpenColorIO.lib. This is not working, the install target still only installs OpenColorIO.lib and the yaml and tinyxml symbols are thus missing.

[nrusch]

Thanks @roelandschoukens. I see that those options were added in a post-1.1.0 commit, so I may see if I can backport them cleanly for internal use. I'll close this for the time being.

I do agree that the handling of the internal dependencies is still a little off. My feeling is that if they are critical to the functioning of the library, they should be compiled into it no matter what.