GZ_PROFILE instrumentation

[ntfshard]

🦟 Bug fix

Fixes #

Summary

Added GZ_PROFILE instrumentation for Ogre and Ogre2 rendering_engines.

Also maybe we can resolve this gazebosim/gz-common#694 PR and if it will be merged we can update Remotery (branch with update mentioned in this PR)

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
• Was GenAI used to generate this PR? If so, make sure to add "Generated-by" to your commits. (See this policy for more info.)

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

[iche033]

we're adding a dependency on a component in gz-common here so just want to check if this can be backported to a release branch? @scpeters or @j-rivero

[scpeters]

yeah, we usually avoid adding dependencies to stable releases

I see some examples of using OPTIONAL_COMPONENTS with find_package, and I also see that gz_find_package supports that argument, though I don't see it in use anywhere, but you should be able to change this instance to find_package if there are bugs in the gz_find_package implementation.

The main issue will be that you would have to wrap the #include <gz/common/Profiler.hh> statement in a separate header (such as ogre/src/GzCommonProfiler.hh and ogre2/src/GzCommonProfiler.hh) that also defines a no-op version of the GZ_PROFILE macro. It's possible but a bit of work

[scpeters]

If we chose to release it anyway, we would need to update the build dependencies in each gz-rendering release repo:

• https://github.com/gazebo-release/gz-rendering10-release/blob/185d20639b62bbbfa2f7b626cbd7c02bf5a8bd53/ubuntu/debian/control#L5-L22

[iche033]

ok got it. If we want to backport this, we can try adding it as an optional component as suggested.

If we chose to release it anyway, we would need to update the build dependencies in each gz-rendering release repo:

If I understand correctly, we don't necessarily need to release it with the profiler dependency. Currently we're just adding remotery profiling points and we expect that users can only do profiling from source build by setting the ENABLE_PROFILER flag to true.

[ntfshard]

I believe by default, it's compile-time dependency (need header for define definition)

[scpeters]

If I understand correctly, we don't necessarily need to release it with the profiler dependency. Currently we're just adding remotery profiling points and we expect that users can only do profiling from source build by setting the ENABLE_PROFILER flag to true.

I believe by default, it's compile-time dependency (need header for define definition)

ok, you're right. I think what I meant to say was that if we wanted to just add profiler as a required component that we would have to update the debian metadata in order for it to compile, but as you point out the profile points wouldn't be active; they would still need to build from source to use the profiling.

So yeah, I think OPTIONAL_COMPONENTS in backports is the way to go