Hmmm... I hadnt thought about passing an alternate soname to the build process, but it makes sense that you could need it for applications which load both a public and private version of OCIO.  

Can you share any more specifics about what you're trying to do? Either way, I'm happy to add a custom SONAME option (if it doesnt already exist).

For example, at SPI we build custom versions of the nuke OCIO plugins (so we can stay up to date with the public master repo), which link to our spi namespaced version of OCIO, and merely by registering our custom nodes first we havent had an issue.  I'm curious why we havent needed to worry about an alternate so name.

-- Jeremy

On Mon, May 6, 2013 at 4:27 PM, Piotr Stanczyk <piotr...@...> wrote:

Hi All,

I am looking to build the core lib with the -D OCIO_NAMESPACE=foo option.  Whilst this builds just fine, I see that the SONAME is unchanged with the above.

So, how do you resolve ambiguities here? Should I be passing in the -D SONAME=foobar in here?

Any tips welcome - thanks

Piotr

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.