Build examples using native CMake

[mjcarroll]

🦟 Bug fix

Fixes (for the most part) Windows examples_build and deduplicates some build steps

Summary

When testing on the newest conda/Visual Studio 2022/Windows 11 configuration I ran into some issues with the "FAKE_INSTALL" step that we were doing in many packages, which was seen to be invalid. I was able to reproduce on Linux by trying to use the "ninja" generator for CMake.

After some investigation, I found that FAKE_INSTALL was actually causing the packages to be built twice, which adds significant overhead to the build.

This is an alternative mechanism for building examples as part of the test suite. Any package that wants to build examples will have to be updated to take advantage of this macro.

This is a pure CMake implementation that doesn't rely on calling out to other scripts/executables.

Downstream PRs:

• gz-math Build examples from CMake rather than executable gz-math#482

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.

[j-rivero]

Let me see if I understand this right: in DEPENDENCIES you can specify gz- libraries that are not being used by the build system of the project but are required to make the examples to build/run? Is this correct? If so, bellow there is a comment:

we are passing in the resolved dependency directories via -Ddep_DIR=${dep_DIR}

How does this work if a dependency is not in the current buildsystem?

[mjcarroll]

I have a slight rework to this I can push shortly that drops this gymnastics a bit.

Note that this is only necessary for gazebo packages, as they may be built in the same workspace, so this special forwarding happens.

Currently, examples aren't allowed to depend on Gazebo packages things that the containing package doesn't. E.g. gz-gui examples cannot have a dependency on gz-gazebo, as this will introduce circular dependencies.

If an example depends on a non-Gazebo package, then typical find_package infrastructure should work.

[azeey]

I finally got around to reviewing this. Sorry for the long delay.

My main issue is that we're adding all the resolved dependency directories when it doesn't seem necessary. Maybe something is misconfigured in my local system and there's a real need to do this.