Merge RC-3 to master

[kdt3rd]

This is a large body of changes, re-organizing in prep for a 3.0 release

[lgritz]

Should we just bump the minimum to 3.12? There are a bunch of other projects in the ecosystem that require at least 3.12, so it's not really like users are making due with 3.10 and we'd be upsetting the apple cart.

[lgritz]

Oops, some of OIIO's CI tests are failing since this merge, lots of messages about

ISO C++17 does not allow dynamic exception specifications

It seems that the OpenEXR CI doesn't specifically test VFX Platform 2021, so we're not noticing if we break it under C++17.

[lgritz]

Hmmm... actually... a whole lot of the ASWF docker containers got updated today. It could have been that? I should dig a little more before blaming this PR with certainty. Though it is still true that OpenEXR's CI simply doesn't test VFXPlatform 2021, so it can be hard to tell when things break.

[lgritz]

Scratch that. I just watched Borat Subsequent Moviefilm, and clearly my brain is fried. The particular OIIO CI test that is breaking is the "bleeding edge" test using the top of tree master of all the dependencies, and for that one I'm not using any ASWF docker image at all (because none of them have gcc10). And my VFXPlatform 2021 test is passing fine, so OpenEXR is NOT broken against gcc9 + C++17. It's only gcc 10 that's can't build OpenEXR.

[xlietz]

I will add VFXPlatform 2021 CI this week. I missed that we had containers for it now. Once OpenEXR is fixed to work on gcc10, I can add a pass for that as well.

[lgritz]

Sorry for the panic. I now believe that OpenEXR master is likely fine. The problem I believe is a whole lot of confusion when OIIO's FindOpenEXR picked up an OLD Imath elsewhere on the system. (Why does my package maintain a FindOpenEXR.cmake instead of using the proper exported configs? Mostly because we still support building against Imath/OpenEXR older than when we started exporting config files.) It was that old Imath that still had the old throws that were anathema to C++17. Again, my current understanding is that this PR from Kimball is probably fine.

But this fire drill is a good simulation of the kind of confusion that other users (er, and their automated CI builds) are going to encounter when trying OpenEXR 3 for the first time.

[kdt3rd]

lg-

I compile with gcc 10.2 at home (run Arch Linux), which works fine? I agree this will be a big shift for people, with a bunch of stuff to update.

-k

[lgritz]

Yes, please ignore my panicked rambling.

The problem was not gcc 10, it was not C++17, and it wasn't even really any changes to the OpenEXR code from your merge.

I believe the problems all stem from my own CMake build system expecting OpenEXR 2.x and not being prepared for the new layout, target names, and split between OpenEXR and Imath. Somehow it got itself into a state of including VERY old imath headers elsewhere in the system and mixing them inappropriately with the new openexr libs.

Today I'm wrestling with my build system to try to make it work across several different OpenEXR versions (including some so old that they don't have exported config files and targets at all).