[cmake] fix FindOpenEXR.cmake so it can deal with windows debug libs with _d suffix

[pmolodo]

Description of Change(s)

Default debug builds of OpenEXR 2.3.0 on windows create libraries with a "_d" suffix.

The current FindOpenEXR.cmake included with USD can't deal with this, and will therefore fail to find OpenEXR. This happens even with the supplied build_usd.py, if you try to build in debug mode on windows. This fix will work both with build_usd.py, and with cmake builds with a user supplied OpenEXR.

Fixes Issue(s)

• USD can't find debug OpenEXR libs on windows

• I have submitted a signed Contributor License Agreement

[meshula]

This is a good solution for debug builds.

Someday, not necessarily as part of this PR, it would be nice to engineer the find script to make an interface library, so that the debug and release information could both carried through the build. The use of _LIBRARIES convention stands in the way of creating vcproj files that can build for Release or Debug, but the interface library scheme does allow for it. OpenEXR 2.5 and greater set things up in the modern cmake way with namespaced OpenEXR and Imath interface libraries, and the script could pass that much richer information through as is. Unfortunately OpenEXR 2.4, which is in the vfxplatform until VFX2019, does not have this nicety, so we're going to need to maintain the find script for a few more years. Or issue a 2.4 maintenance release of OpenEXR.... hmmmm

[pmolodo]

Larry Gritz made a much nicer FindOpenEXR.cmake which creates imported targets for 2.4+, as part of OSL:

https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/blob/main/src/cmake/modules/FindOpenEXR.cmake

Would be nice to migrate to that, but it has it's own license, plus it would need to be verified to work with USD, yada yada.

It also currently doesn't really deal elegantly with the debug vs release libs things - it just adds in a check for libs with _d suffix, which is better than nothing, but doesn't do anything where it can find both, and attach them to targets based on the current config.

[jilliene]

Filed as internal issue #USD-7345

[pmolodo]

Updated this because I was going through old PRs... but given that:

• USD now only looks for the OpenEXR package if it can't find Imath
• Currently recommended OpenEXR version (3.1) uses a separate Imath lib

...I actually think a better solution now might be to simply require OpenEXR >= 3.0, only look for the Imath package, and remove FindOpenEXR.cmake entirely, so we don't need to keep maintaining it.

[meshula]

Thank you for that note @pmolodo, you're correct that we don't need the Find script any more since OpenEXR now publishes working cmake config files!

[jesschimein]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).