Fix OpenEXR3 compatibility (raises minimum version) and use upstream's CMake Config

[a17r]

We have been carrying this patch downstream since 2022 without bugs reported: https://bugs.gentoo.org/833492

OpenEXR 3 release and compatible upstream CMake Config goes back to the beginning of 2021. Last commit to OpenEXR 2.5 branch was made more than 2 years ago and it is safe to say that was the last one.

Other distributions applying similar patches:
https://gitlab.archlinux.org/archlinux/packaging/packages/openscenegraph/-/blob/main/openscenegraph-openexr3.patch
https://src.fedoraproject.org/rpms/OpenSceneGraph/blob/rawhide/f/OpenSceneGraph-openexr3.patch

[AnyOldName3]

I think this falls squarely into

This fork exists for OpenMW-specific improvements that are expected to break other apps. It's not appropriate to use this for non-OpenMW OSG-based projects unless their developers have vetted our changes and confirmed that their apps are compatible.

territory. We'll leave it here as I know some distros would rather carry a patch they found in a PR than something from other sources, but we won't be merging it as anything OpenMW doesn't use is explicitly not supported by this fork.

[a17r]

Please note that, since find_package(OpenEXR) makes for an automagic dependency, everyone building osg-openmw needs to deal with a likely build failure without manually disabling CMake finding the package, if OpenEXR-3 is present.

[AnyOldName3]

Within the scope that we support, it's expected that -DBUILD_OSG_PLUGINS_BY_DEFAULT=OFF is used, so the plugin wouldn't be build at all.

[Capostrophic]

If we don't want to maintain the OpenEXR plugin, could we consider removing it altogether?

[a17r]

I was wondering already about some new option OSG_OPENMW_ONLY_PURPOSE which could tick the default state of dependency options using CMakeDependentOption

[AnyOldName3]

Removing things is more effort than ignoring them, and ignoring them has worked fine for the last decade. I don't want to put work into making it harder for other applications to use this fork. I want to minimise work.

If we were changing the defaults for options, which this fork already does in a couple of places, and used to in even more, we'd just change the defaults. Having an option to opt into the whole raison d'être for this fork is obviously silly, as the default would be to have it, and in this specific case, someone opting out of OpenMW-specific stuff could already set -DBUILD_OSG_PLUGINS_BY_DEFAULT=ON to opt out if we changed the default to OFF.

Also, CMakeDependentOption is unnecessary if you're just setting the default value based on another option - variables in the default value for the base option command are expanded. Its point is to hide variables in the Qt/Curses GUI tools based on a condition, and we wouldn't want to hide certain plugins. It doesn't inspire confidence in these PRs when you post misunderstandings of what the docs say, and means I have to spend extra time checking everything when reviewing stuff.

[Capostrophic]

I guess that's fine, I just thought there could still be some way to find a compromise that would reduce the third party package maintainer burden without increasing ours (well, mostly yours).

It doesn't inspire confidence in these PRs when you post misunderstandings of what the docs say, and means I have to spend extra time checking everything when reviewing stuff.

Unnecessarily prickly. They are just trying to help and aren't arguing in bad faith. I assume you're under the weather or tired and it's rubbing off?

[AnyOldName3]

I guess I could have phrased it better. I'm just trying to clarify why I'm not giving benefit of the doubt and merging things that wouldn't affect OpenMW if they broke.