Yes, we use OCIO extensively, and by coincidence, for the last couple releases,
I've been the one who builds OCIO at my facility, and I'm 100% sure that the
current releases of OCIO and OIIO work fine together. If they didn't, our
production builds would come to a screeching halt.
I'm as frustrated by the OpenVDB situation as you are, but you should know that
it will definitely be fixed for OpenVDB 9. There is work in progress to address
the problem. (And I'm told that OpenEXR is an *optional* dependency for
OpenVDB, so it was not strictly needed if you use the right build flags.)
For the sake of explaining how reasonable people can still create these
fiascos, let me give some details on how OpenEXR + OpenVDB got into this pickle:
These projects may be under the same organization, and even have some
individual developers who participate in coding for both projects, but they
aren't on the same release schedule. OpenEXR was supposed to release 3.0 in
early Fall 2020, but the release got delayed, dragged on, and it missed the
deadline to be included in the VFX Reference Platform 2021, which instead
stayed with OpenEXR 2.4 for its 2021 recommendation. Most of the VFX world,
therefore, kind of ignored OpenEXR 3.0 because they really couldn't use it,
since it was incompatible with the version 2.4 they were forced to use with the
big DCC apps. OpenVDB, busy people that they are, continued to CI test and
ensure that they were working with the VFX Platform recommended versions of
their dependencies, but not other versions that their clients weren't using.
(Understandable, though in retrospect, perhaps short sighted.)
It was only in late summer 2021 that VFX Platform confirmed that for 2022,
their OpenEXR recommendation would be bumped to 3.1, and then suddenly OpenVDB
got surprised because they had been busy and had never quite gotten around to
building support for the *not VFX Platform recommended* OpenEXR 3.x, and they
had sinc released OpenVDB 8.0 and 8.1 that were not prepared to build against
OpenEXR 3.x when everybody started wanting to switch to it because of the new
VFX Platform recommendation. Now they're scrambling so that the recommended
2022 OpenVDB (the forthcoming 9.0) will definitely play nice with the 2022
recommended OpenEXR (3.1).
Now, sorry my friends, but I think this was a big blunder for OpenVDB to not
have CI tests all along against the *latest* releases of all their
dependencies, even if those are more recent that the current VFX Platform
recommendation. Lessons learned, ok?
OIIO and OSL test against the last several VFX Platform configurations, but our
CI also tests specifically against the latest released versions of our major
dependencies, as well as a "bleeding edge" test where we build against the
top-of-tree master of some of the most critical dependencies. So we can never
be surprised by a new release of the most important dependencies, we will have
found and fixed any such problems months before their releases. (The downside
is that sometimes this bleeding edge test fails spuriously when bugs are
checked into the development branches of those projects. In fact, that test is
broken at the moment because of a problem with OpenEXR, though a fix is under
review now and awaiting a merge, so I expect the test to pass again in the next
few days.)
Anyway, like I was saying, there was a brief dance of coordination when after
we released the OIIO in which we eliminated the redundant symbols (thus
necessitating explicit linkage of libOpenImageIO_Util in certain cases where it
coincidentally had worked before), the existing release of OpenColorIO would
not have built against it properly. I think that has since been fixed, but I'm
not 100% sure in which releases. But I know they are aware of these problems on
the OCIO side -- we are all in frequent contact with each other.
-- lg
> On Oct 3, 2021, at 4:54 PM, Richard Shaw <[email protected]> wrote:
>
> On Sun, Oct 3, 2021 at 6:22 PM Larry Gritz <[email protected]
> <mailto:[email protected]>> wrote:
> Sorry to dribble this out over multiple emails.
>
> The entire build log you linked to below is a build of OCIO, not OIIO. They
> will know better how to diagnose the problem with their build.
>
> Sorry, my intent was to see if there was poor communication before posting an
> issue with OCIO.
>
> There was only one version in place, this is a distro level build, not
> something performed on my computer, so your 2nd email may be the cause.
>
> My point is that OIIO and OCIO are coupled and that changes in either should
> be coordinated. And this is not unique to OIIO.
>
> When OpenEXR was updated and Imath separated, OpenVDB was not updated at the
> same time to be compatible, which is ironic as they are both ASWF controlled.
> I actually manually ported OpenVDB to OpenEXR/Imath 3, which was later
> accepted. My point is that it should not have been necessary.
>
> Upstreams of known dependencies should talk to each other. As a package
> maintainer finding these issues is problematic on several levels.
>
> API changes often directly impact maintainers quality of life and it's 100%
> preventable. I do this as a volunteer and have devoted 1000s of hours to this
> endeavor.
>
> Sorry, this is not 100% directed at you, actually your insentance on ABI
> compatibility makes OIIO one of the easier packages to maintain overall but
> just triggered me in this instance.
>
> Thanks,
> Richard
>
> _______________________________________________
> 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
