Hi Piotr, congratulations with the 2.0 release! We've just ported mental ray to OpenEXR 2.0, and I'd like to share some thoughts on the namespaces & co, for the future versions. Conflicting namespaces and symbols is a big headache as long as products with code from multiple parties are involved, and I am glad that 2.0 started to address this.
The Imf and Imath were never a big deal. I've just used something like -DImf=MI_Imf etc. on the compiler options, and that worked just fine. Much bigger issue is that mental ray is built with STLPORT. We do it primarily in order to avoid dependencies and conflicts with 3rd party and OS versions (applies for Linux llibstdc++). So, we use the STLPORT in a custom namespace. I would love OpenEXR to provide an alias to std:: That one just cannot be #defined-off like Ilm's namespaces. As of now, we patch the complete source code replacing std:: / using namespace std with our namespace alias. Another wish would be to have a base class used for OpenEXR's classes. In my case: mental ray uses its own memory system. There is a strong need to put new/new[]/delete/delete[] operators on top of that proprietary memory management. However, as mental ray runs inside of 3rd party applications, it is not feasible to override the global new/delete operators. The solution which we currently use is a base class with overloaded new/new[]/delete/delete[] operators. In order to channel OpenEXR's allocations into that system, one needs to go through the source code and patch it by deriving the classes from that base class. That's 100+ locations, and this is a process which cannot be automated. Best regards, Juri -----Original Message----- From: openexr-devel-bounces+juri=dr-abramov...@nongnu.org [mailto:openexr-devel-bounces+juri=dr-abramov...@nongnu.org] On Behalf Of Piotr Stanczyk Sent: 14 January, 2013 19:31 To: openexr-devel@nongnu.org Subject: Re: [Openexr-devel] Patch-compatibilty with versioned namespaces Hi, +1 on what Peter mentioned. You can do one more thing with the --enable-namespaceversioning flag, it can take an optional value. For example, you may want to pass --enable-namespaceversioning=DNeg, in which case the DNeg suffix will be used for the internal namespaces. (That should be reflected in the status output of the configure script) The build process will then generate sonames of the type: libIlmThread-DNeg.so.10 with the corresponding library names: libIlmThread-DNeg.so.10.0.0 It seems that the choice of this configure option on my part was less than obvious - I'll update the documentation accordingly. Piotr ________________________________________ From: openexr-devel-bounces+pstanczyk=ilm....@nongnu.org [openexr-devel-bounces+pstanczyk=ilm....@nongnu.org] on behalf of Peter Hillman [pet...@wetafx.co.nz] Sent: 13 January 2013 22:45 To: openexr-devel@nongnu.org Subject: Re: [Openexr-devel] Patch-compatibilty with versioned namespaces Hi Ollie! > Am I right in saying that, without versioned namespaces, patches are always > binary compatible and minor versions always incompatible? Yes, this should be the case > Is there a patch-compatible namespacing method already provided (and if so, > what is it)? The existing method is patch-compatible: patches will still be released with the _2_0_0 namespace. We will only move from on from _2_0_0 and .so.20 if binary compatibility has to be broken. So, v2.0.X releases would all use the _2_0_0 namespace for all classes. If binary compatibility needs to be broken, we will most likely update the effected libraries to namespace _2_1_0, at which time the .so version number will be bumped up to .so.21. This way, a large application can safely load both old and new libraries. Indeed, this ability is one of the reasons for switching to this versioned namespace scheme. > What's the soname version number based on? The soname version number (probably) tracks the first two digits of the namespace version number. (the last digit in the namespace version is somewhat misleading, as it doesn't imply patch level: it's there only for an edge case of providing multiple versions of an object within the same .so but in different namespaces, which we're really hoping we don't need to do in official releases, but for internal builds might be the easiest way out of a hole) At least, that's my understanding of the plan! Peter On 09/01/13 03:10, Ollie Harding wrote: > Hi, > > I wonder if somebody could clarify some versioning info for me, or point me > at the bits of the docs which I've skimmed over too quickly? > > I'm building v2.0.0 using the --enable-namespaceversioning flag for > ./configure, which gives me e.g. > > Imath_2_0_0::SingMatrixExc::~SingMatrixExc() > > This will of course mean that I cannot drop in a future v2.0.1 library since > the Imath_2_0_0 symbols will no longer exist, although the library will > presumably still share the .so.20 soname. I suspect I'm using the wrong > method of making a unique namespace, as I in fact want a namespace which > retains patch compatibility, e.g. maybe Imath_2_0. > > So my questions are: > > * Am I right in saying that, without versioned namespaces, patches are > always binary compatible and minor versions always incompatible? > * Is there a patch-compatible namespacing method already provided (and > if so, what is it)? > * What's the soname version number based on? > > Many thanks, > > Ollie > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
