The CMake variable OIIO_NAMESPACE lets you customize namespaces (by version or product) so that "your" OIIO won't clash with another that's in a separate library.
I think it would be a great addition to modify the build system to actually incorporate the major/minor version into the naming of the dll/dso, and/or the namespace itself (perhaps optionally; we can debate the pros and cons). In any case, don't think that the current naming and namespace conventions are by design or are beloved. It's just what settled as "good enough", but it can always stand to be improved. I think the best way to proceed is for somebody with the knowledge and motivation to propose a specific solution in the form of a pull request. On Aug 28, 2011, at 5:44 AM, Ben Houston wrote: > Hi all, > > I was just recently debugging an issue related to Arnold's and Fury's > usage of the OpenImageIO.dll library that I think I should explain so > that it can possibly be avoided through a design change in the future. > > Because OpenImageIO is a constantly advancing open source project, > different OpenImageIO.dll included with various software packages can > have different API signatures, all of which are slightly incompatible > with each other. This normally wouldn't be an issue, but Windows uses > a single DLL namespace for each processes. This means that if one > plugin in Softimage, say plugin "A", loads one version of > OpenImageIO.dll, if another Softimage plugin, say plugin "B", attempts > to load another OpenImageIO.dll at a later time (based simply on the > order Softimage decides to load all of its installed plugins) that is > a different version (different API) that the DLL loaded by plugin "A", > the second plugin will fail to load because Windows thinks both DLLs > should actually be equivalent because they have the same name even > when they have different APIs. > > This is a real risk with OpenImageIO because the API is often changing > with each release (or at least it has been) and it is compiled by > default as an DLL who name remains exactly the same across all these > changes. As OpenImage becomes more popular and if its API keeps > changing, these types of conflicts will become more common. It might > actually become really problematic if Softimage (or Maya) ever decided > to include a version of OpenImageIO.dll in its default installation as > they would likely pick a version much older than the one included in > the rapidly updating Arnold packages, but then Arnold would not be > able to access the newest features offered by OpenImageIO. > > Of course everyone can start to compile OpenImageIO.dll with a unique > name, but there is a simplier solution. I think that if the OpenImage > DLL name had a version (major and minor) in it (as Boost's and > Microsoft's runtime libraries do) that would address things to some > extent and it would be my recommendation to the OpenImageIO guys to do > this. > > But for us (Exocortex) this isn't an immediate necessity as we are > going down the custom OpenImageIO.dll name for the time being to avoid > these issues. > > -- > Best regards, > Ben Houston > Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom > http://www.exocortex.com > _______________________________________________ > 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
