Drop support for OGRE2 < 2.2

[mjcarroll]

🦟 Bug fix

Summary

This is a pretty substantial cleanup of the OGRE2/OGRE-Next logic.

• Allows for OGRE-2.3 packaged by OpenRobotics from packages.osrfoundation.org
• Allows for OGRE-Next from Conda on Windows, Linux, and Mac
• Allow for OGRE-next to be built from source in the same colcon workspace
  • Requires: https://github.com/OGRECave/ogre-next/pull/324
  • Requires: https://github.com/mjcarroll/ogre-next/commit/262471390763eb05088e379291ae9d284b28a05f

Drops support for < 2.2 and unifies the logic between Linux and Windows.

Checklist

• [ ] Signed all commits for DCO
• [ ] Added tests
• [ ] Updated documentation (as needed)
• [ ] Updated migration guide (as needed)
• [ ] Consider updating Python bindings (if the library has them)
• [ ] codecheck passed (See contributing)
• [ ] All tests passed (See test coverage)
• [ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[mjcarroll]

CC: @darksylinc

This is going to get us most of the way on deb/conda/source compatibility

[mjcarroll]

As an alternative @darksylinc has proposed that we may just be able to use upstream FindOGRE, but I haven't tested this on all platforms yet.

[j-rivero]

Sorry for being late to review this and now that we have released gz-cmake3 seems a disruptive change to me. Actually the diff does not provide very useful information about what was changed so it is more like a new module from scratch.

Probably at this point there are no more consumers than the Garden family but it would be great to preserve the module as it is if it is not fully compatible with the one in the current code. Several options:

• Most compatible change: we preserve current module, deprecate it and move these changes to be a new CMake module with a new name. This would require small changes in consumer inside Garden.
• Try a transition by default: we merge these changes but keep a copy of the old module with a different name. Mention it in Changelog/Migration so if it is failing for anyone the change to keep previous behaviour is just a name in find_package.

Whatever you prefer @mjcarroll works for me.

[j-rivero]

As an alternative @darksylinc has proposed that we may just be able to use upstream FindOGRE, but I haven't tested this on all platforms yet.

Aaah that would be great, indeed.

[mjcarroll]

Probably at this point there are no more consumers than the Garden family but it would be great to preserve the module as it is if it is not fully compatible with the one in the current code. Several options:

That was my thought as well. gz-cmake3 should only be used by the garden collection (unless there are other people out there using it). I think default behavior should be okay in this case, but I'm happy to preserve the functionality as well.

Since there is no rush, lets hold on this until I have an opportunity to test upstream cmake logic and see if that can replace this.

[iche033]

I tested building gz-rendering7 with the changes in this PR and also https://github.com/gazebo-forks/ogre-next/tree/gazebo/v2-3 built from source in a colcon workspace. I saw that gz-rendering was able to find ogre-next 2.3 but had issue with include paths. I get a few of these compile errors:

/home/iche/code/ogre_ws/install/include/OGRE-Next/Hlms/Unlit/OgreHlmsUnlit.h:32:10: fatal error: OgreHlmsBufferManager.h: No such file or directory
   32 | #include "OgreHlmsBufferManager.h"