Sorry, took me a couple days to get to this.
As far as Qt goes -- At the moment, the only Qt that comes into play is to link
against it for iv. None of OIIO's "libraries" use it, so there is no specific
danger that OIIO's Qt needs will conflict with that of Maya or any other app
(because even if those other apps *also* incorporate OIIO, it won't be the
parts that need Qt).
But that just pushes the peas around the plate, as I like to say. An
OIIO-embedding application could just as easily have conflicts with OpenEXR,
Boost, or whatever.
As you know, that kind of thing was a problem long before OIIO came along --
we've all been at facilities that needed to use apps A and B, each of which
require incompatibly different versions of the same dependent library. It's
maddening.
I don' t have any magic solutions. But I'm happy to try to rearrange things as
much as necessary to make it easier.
We already support an optional wrapping namespace for OIIO itself, so you ought
to be able to make a version that does not conflict with any commercial apps
that also embed OIIO. (Though, as you pointed out, that may make it tricky to
have a DSO imageio plugin that works with both your namespaced and a
product-embedded version of OIIO. Sorry, no bright ideas there.)
To answer your question directly, I do think that if a commercial app wants to
embed OIIO, it should probably use the namespace wrapping, as you suspected.
For the problem of your having a weird custom Qt (or other library) used by a
3rd party App that would prevent you from having a standard Qt in the normal
place... well, maybe we can alter our CMake files to allow an explicit override
for where OIIO looks for Qt (or even overrides for every major dependency).
Would that help?
I'm open to other suggestions.
-- lg
On Apr 12, 2012, at 8:22 AM, Colin Doncaster wrote:
> Hello -
>
> Sorry for the Quicktime/Qt confusion - in my last email, once I corrected
> myself, I was using Quicktime for the Apple Quicktime Movie format and Qt for
> the Nokia Qt application framework. I do understand the differences, it's
> probably a bad habit to refer to them both as Qt ( though, developing OSX
> applications you use QTkit for quicktimes - maybe that's where it stems from
> ).
>
> In reference to the Qt discussion, the Qt that Maya uses is Nokia's Qt
> Application Framework - Maya 2011 links against Qt 4.5.3 ( or more
> confusingly the qtsdk-2009.04 ), Maya 2012 links against Qt 4.71 and rather
> annoyingly 2013 now uses an Autodesk customized version of 4.7.1 with Nuke,
> Katana and all of the other common VFX tools possibly using different
> versions. I understand the only iv requires Qt, but as far as installation
> instructions and integrating it into a pipeline it might be clearer to point
> out what version of Qt ( the application and GUI framework ) is
> compatible/minimally required. This is also why I wasn't in favour of 'port
> install qt4-mac', but I guess if developers are using OIIO and working with
> all the different Qt flavours they'll be able to sort it all out.
>
> This leads to your last point about how OIIO is integrated into multiple
> products and across multiple platforms/systems. Is the assumption that each
> product will manage their OIIO needs individually and the recommended
> deployment method is to always use a namespace? Although OIIO doesn't
> apparently have many dependencies, it does rely on specific versions of
> OpenEXR, libtiff, libjpeg, libpng and others ( which are usually already
> available on most unix installations including OSX but not Windows ) - so in
> general, a safe means of deployment to avoid symbol clashing and version skew
> with other products is to statically link all dependencies into a static
> library using a namespace?
>
> I'm not looking for a long answer, but more "yes - that would be the best way
> of handling it" and to also hear from other product developers on their
> thoughts how to best handle this? Right now we wrestle with various versions
> of Python, boost etc. and it would be good to know what versions of OIIO
> product developers are looking at supporting and why?
>
> I apologize if my initial email wasn't to the point, maybe the initial
> question should have just been - "how are commercial developers integrating
> OIIO into their products for mass release on multiple platforms and for
> varying pipelines?".
>
> Thanks
>
> --
> Colin Doncaster
> Peregrine Labs
> http://peregrinelabs.com
>
> On 2012-04-12, at 1:32 AM, Larry Gritz wrote:
>
>> On Apr 11, 2012, at 10:37 AM, Colin Doncaster wrote:
>>
>>> Hi Larry -
>>>
>>> By QT I meant Quicktime, not the QT GUI toolkit.
>>
>> Oh. Well, I hope you can see how I was confused. There's an ongoing
>> detailed discussion about building Qt the GUI toolkit, and you had
>> participated in that discussion just a couple days ago. (I hope you knew it
>> was Qt, not Quicktime, that you were discussing.)
>>
>> Quicktime has barely been mentioned at all over the years... a couple months
>> ago somebody said they'd like to write a format reader that can pull frames
>> out of a Quicktime file, and I replied that I suppose it could all fit into
>> the API as long as the plugin made a movie file look rather like a multiple
>> subimages in the file. I don't think we've heard back on this list since.
>> But I can see it being useful, so my thinking is that as long as the plugin
>> simply skips building if Quicktime is not found, it obviously can't break
>> any other parts of OIIO, so I'd be inclined to accept it (assuming a patch
>> is forthcoming and meets our usual quality threshold).
>>
>>
>>> The way I was looking at it was more rolling your 1-4 into "core" with a
>>> baseline of image formats, any new images formats or less common formats
>>> along with Quicktime or Mpeg or other additions could end up outside of
>>> Core.
>>
>> I'm not sure I understand how this helps you. If you wanted to use the new
>> format, you'd need to get and build both projects. If you didn't want to
>> use the new format... well, it already wouldn't be a burden to you, right?
>> What am I missing?
>>
>>
>>> Although port install qt4-mac does work, this isn't ideal when you're
>>> building a product that needs to integrate with multiple versions of QT (
>>> Maya 2011 and Maya 2012 ) as well as making sure the binaries built are
>>> usable on all of our users system, on Windows, Mac and Linux.
>>
>> I'm confused again. In this paragraph are you talking about Qt GUI toolkit,
>> or Quicktime? "qt4-mac" is Qt GUI.
>>
>>
>>> The reason I brought up varying OIIO builds is that it's likely that are
>>> product might be loaded along with Arnold, which links against it's own
>>> OIIO and may not support the desired formats etc. I understand we can wrap
>>> ours up with a unique namespace but it would be nice to be in a position to
>>> use the shared libraries.
>>
>> Aha, this might be the meat of the matter. But help me discern the main
>> problem.
>>
>> The OIIO embedded in Arnold would be properly namespaced, so should not
>> conflict with any other OIIO use in different apps, or different releases of
>> OIIO elsewhere on your systems. Are you worried that you would have a
>> custom format reader that would not be read by Arnold's embedded OIIO
>> because it's a different version? I think that Arnold's use of OIIO is only
>> in two areas: the texture system (and there is a very limited number of
>> formats suitable for use as textures), and for output. Is there a specific
>> format that you're worried about?
>>
>> Or are you worried about shared library use on your systems generally?
>> Shared libraries are the devil's work, I'm convinced. I'm all ears if you
>> have any ideas about how we can mitigate any shared library problems. Is
>> there a specific current dependency you want us to eliminate? Or a proposed
>> future dependency that has you worried? To bring this back to the original
>> topic, I'm not aware that any of the submitted GSoC proposals pull in any
>> new dependencies or shared libraries that we aren't already using, so I'm
>> not sure how they affect the shared library problem.
>>
>> Sorry if I'm having trouble locking on to exactly what your concerns are. I
>> really do want to help.
>>
>> --
>> Larry Gritz
>> [email protected]
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
