- FindOpenEXR updated to find new lib names and separate Imath. Add it all to the list of OpenEXR include dirs and libs. This keeps things compatible with both version 2.x and 3.x for now, and doesn't require changes outside the find module.
- FindOpenImageIO updated to link to separate OpenImageIO_Util for new versions, where it is required. For older versions, we can not link to it because there will be duplicated symbols.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- exr3 (branched from master)
- Build Status
Buildable 20603 Build 20603: arc lint + arc unit
Event Timeline
Comment Actions
This is needed for T95206: Libraries Changes for Blender 3.2. But I think it would be good to commit this already to the 3.1 branch to make it easier for Linux distributions to build Blender without custom patches.
In theory this should not break existing Blender builds with the older libraries, and make the new libraries just work without any manual configuration.
Comment Actions
CC @Bastien Montagne (mont29) since this also affects the install_deps.sh case.
I tested that this works with old and new precompiled libraries on macOS, and with old precompiled libraries on Linux.
Comment Actions
I've tested the patch and chatted with Brecht about some changes that was needed for it to build on my Linux machine.
I have tested it with both OpenEXR 2 and 3. Seems to work well with my changes.
Comment Actions
- Unset temporary cached cmake variables. I will create a follow up patch for other libraries where this cleanup would be nice to have as well
- Change Int64 it uint64_t. It seems like Int64 is no longer defined in openexr 3, the functions that used Int64 in this case uses uint32_t in the upstream code.
- Make includes compatible with both openexr 2 and 3.
Comment Actions
Some of these changes in code were already in our lib update branch (tmp_lib_update_32), also not entirely convinced C/CPP changes belong in a cmake update diff
Comment Actions
On second thought, if this builds properly against both 2.x and 3.x may as well land it early inc cpp changes, so conditionally accepted based on the answer to that question being yes.
Comment Actions
@Ray Molenkamp (LazyDodo) Right, the idea was to land this early even if the changes are already in a branch. (For Blender 3.1 and 3.2)
This is so it will be easier for linux distros to build and package blender as more and more of them are starting to migrate from openexr 2 and ilmbase to openexr 3 and imath.
Comment Actions
These are in tmp_lib_update_32 indeed, I want to pull them out of that and commit them to blender-v3.1-release instead.
We can split this patch up into 3 commits when it lands (OpenEXR C++, OpenEXR cmake, OIIO cmake). For testing and review it's easier in one diff.
| source/blender/imbuf/intern/openexr/openexr_api.cpp | ||
|---|---|---|
| 150 | Note that the old Int64 defined by OpenEXR 2 was in fact unsigned, so this works for both. | |
Comment Actions
For reference: the OpenEXR 3 porting guide suggest detecting if the Imath library exists to differentiate between 2 and 3, and the Fedora Blender package patch does the same.
We do a more complex check to avoid potentially using system Imath and precompiled OpenEXR together.
Comment Actions
Patch builds and works fine for me, besides getting this compile warning in all affected files:
cc1: warning: /usr/include/Imath: No such file or directory [-Wmissing-include-dirs]
CMake here uses system OpenEXR (2.5), and install_deps-compiled OIIO.
Comment Actions
Build passing on all platforms now:
https://builder.blender.org/admin/#/builders/18/builds/319
I've got this diff split into 3 commits here locally, ready to commit.