On Thu, Nov 17, 2011 at 8:55 AM, Jon Ciesla <limb@xxxxxxxxxxxx> wrote:
>
>> I'm working on packaging OpenColorIO for Fedora and ran into an issue
>> with bundled libraries.
>>
>> The project is currently statically compiling in yaml-cpp, tinyxml,
>> and lcms. Upstream doesn't have a problem with unbundling lcms, but is
>> not sure about the other two, here's his explination:
>>
>> hmmm.... some of the things in ext are not exposed in the public OCIO
>> API; and not being a build expert I'd prefer to not expose additional
>> runtime library dependencies. (tinyxml + yamlcpp, for example).
>>
>> With your implementation, on a fedora build that had one of these
>> libraries installed, would you link to the xml / yaml so(s), or would
>> it use the .a statically at build time? I'd hate to have the
>> dependancies in the core library change depending on build options.
>> What if I pulled in these two libraries into 'core' as source files?
>> (it used to be this way, actually). I'm fine with picking up lcms, etc
>> externally. But i'd like core to be self-contained...
>> ---
>>
>> Are there technical reasons these libraries can not be unbundled?
>
> Only if he's significantly modifying the bundled libs and upstream won't
> take the changes. If you unbundle and build against the system versions,
> and it works, that's what you need to do. Always link dynamically if at
> all possible.
Ok, so the public/private API's won't be a problem?
He did mention they were patched, some of it for build reasons (no
problem) but some of it was to make it work. He's going to check to
see if those patches have made their way into upstream.
The last problem is a strange one. They have a library, PyOpenColorIO
that provides both C++ symbols, but also python bindings. I assume
they need to go in /usr/lib{,64} but should they also get symlinked to
/usr/lib{,64}/pythonX.X/site-packages?
Thanks,
Richard
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
