CMake touch-up

[a17r]

Check for POLICY CMP0069 directly instead of cmake_policy()

Cleanup FATAL_ERROR from cmake_minimum_required

Build examples only if NOT ANDROID

---

These are cosmetic only, but cleanup nonetheless. Deeper subdirectory levels were omitted deliberately in the endif() cleanup so it does not dominate too much here:

Cleanup legacy CMake else() conditions

Cleanup legacy CMake endif() conditions

Remaining:

$ find . -name "CMakeLists.txt" -exec grep -lie "endif\s*([a-Z0-9].*)" {} \;
./src/osgPlugins/3ds/CMakeLists.txt
./src/osgPlugins/python/CMakeLists.txt
./src/osgPlugins/OpenCASCADE/CMakeLists.txt
./src/osgPlugins/ffmpeg/CMakeLists.txt
./src/osgPlugins/fbx/CMakeLists.txt
./src/osgPlugins/lua/CMakeLists.txt
./src/osgPlugins/ZeroConfDevice/CMakeLists.txt
./src/OpenThreads/win32/CMakeLists.txt
./applications/present3D/CMakeLists.txt
./examples/osgcluster/CMakeLists.txt
./examples/osgstaticviewer/CMakeLists.txt

[AnyOldName3]

Regarding Check for POLICY CMP0069 directly instead of cmake_policy(), the check is super old and was literally just there to check what it was checking, i.e. that CMake has the concept of policies, as the first things in the block used to be policies that were added in the same version of CMake as the concept of policies. Later, one was added with a version check. These were stripped out the other day when the minimum version was increased and they became on by default, and really, the existing check should have been removed at the same time.

The CMP0069 bit was added in 2021, and was missing its corresponding version check, so technically it broke support for versions below 3.9.

Technically, the commit's not swapping a wrong check for the right check, it's removing an old redundant check and adding a missing check that should have been added years ago. This doesn't really affect whether or not we want the commit, but I thought it was worth clarifying as the commit message could mislead someone about the history.

The else(CONDITION) and endif(CONDITION)` stuff wouldn't have been desirable for most of the history of this fork, as it's easier to maintain a fork when it diverges from the upstream as little as possible, and most people who know CMake know about this condition syntax (and some weirdos even prefer it). I guess we're at a point where something like this is more likely to stop someone making a mistake than it is to contain a mistake itself or make keeping this fork up to date with upstream harder.

[a17r]

I guess we're at a point where something like this is more likely to stop someone making a mistake than it is to contain a mistake itself or make keeping this fork up to date with upstream harder.

Having read that, I see that 3.6 branch is several hundred commits behind osg upstream (which got commits in ever decreasing frequency until the end of 2022, which is where the flightgear fork is based off). Was there a plan to still rebase/merge or cherry-pick relevant fixes from there?

[Capostrophic]

OSG master branch broke compatibility, ended up semi-broken and isn't compatible with OpenMW, while the alternative master effort has kind of gone nowhere; OSGoS 3.6 branch is based on the upstream 3.6 branch, which is effectively the only upstream branch that actually works for us. I don't think we're lagging behind it.

[a17r]

I was actually looking at OSG 3.6 branch, but on second try I see that I didn't notice upstream's email address change, so indeed there are only 3 minor commits as diff.

[AnyOldName3]

Yeah, there have been some ill-advised history-rewriting operations on both sides, so it's a nuisance to get a straightforward diff through the GitHub UI.

The upstream versioning scheme is a little weird, with even minor versions being called stable releases (even though they can contain breaking changes that would cause a major version number change in semver), and odd minor versions being called developer releases, which contain a bunch of experiments that might be removed again and are expected to break things. Bug fixes would generally go to an even-numbered branch and master. Robert switched to VulkanSceneGraph work and stopped working on master-branch OSG, with all maintenance work going into the upstream OpenSceneGraph-3.6 branch for quite a while before he decided it was no longer worth maintaining it at all.