I’m using the STATIC lib of Urho3D, and lib Tracy is supposed to live inside of lib Urho3D. However, since Tracy is used everywhere in the Samples by including headers and inserting macros but some of the symbols are just elimiated.
You misunderstood me a little bit. Only the SHARED lib type needs special consideration (what get exported) in order to avoid undesired symbol elimination while building the shared library itself. On the other hand the STATIC lib type does not suffer from this kind of elimination issue. It is basically just a collection or archive of all the objects there are in the said library target. Assuming you only interested in using the STATIC lib type then you can either:
Rely on the existing “librarian” logic that Urho3D library has. If you add a new third-party lib with Urho3D provided macro (i.e not using the vanila CMake command) then it should automatically set thing up for you. The librarian will merge all the objects from the new lib (Tracy) into the libUrho3D.a while the Urho3D target is being built.
Set it up as you have mentioned in your second bullet point. Add a new third-party lib with the vanila CMake command to do so. It should then just build libTracy.a or what have you, which should contain all the objects from this new target. Note that I said, “it should” here as I don’t know anything about this profiling library. In the app then you have to explicitly tell CMake that the app depends on this new library.
As for rbfx, I have checked the work there. The Tracy profiler tool has been integrated into the Editor, which is very impressive. However, I think in Urho, we can keep thing simple by just integrating the client, and use standard Tracy tool avoid the introduction of other dependencies.
AFAIK, the Tracy support for other platforms in rbfx is limited, no Android (yet?) and I must have missed the Release configurations in Visual Studio solution cmake generated?
Ideally, people could have brought Tracy integration into Urho3D from rbfx in a non disrupted community, so my work can be just fixing some issues for it. Anyway, I don’t really think this is a big issue in this case.
Not exactly correct. MinGW builds work fine as long as you do not enable Tracy. Actually problem is quite minor too. MinGW is so even latest SDK does not provide all windows APIs, some of which Tracy uses. What we have to do is load those APIs using LoadLibrary+GetProcAddress.
By default Tracy uses glfw for platform window creation. At very least client would have to be reworked to use SDL, or even Urho3D. That is not a big deal, but an annoyance when it comes to updating Tracy.
My primary reason for integrating Tracy was that Urho3D profiler is unusable on mobiles. Profiling phones over the network works just fine.
URHO3D_TRACY_PROFILING build option toggles this feature, meaning it is optional and can be used when we need the extra profiling ability and the target platform is supported by Tracy. The original profiling related macros and their references are reused and extended.
Edit: (updated due to changes in recent commit)
Pseudo code of build control:
// Tracy used
// Default Urho3D profiling used.
// Profiling off.
Platforms ([x] means the support is validated)
[x] Android (Physical/Virtual)
1. Enable Tracy integration Edit: (updated due to changes in recent commit)
Build Urho3D and its Samples with extra build option -D URHO3D_TRACY_PROFILING=1. URHO3D_PROFILING will be automatically turned off when URHO3D_TRACY_PROFILING is on. This is achieved in UrhoCommon.cmake script.
set (URHO3D_PROFILING 0)
On other platforms or you just want to build your own Tracy server, you can follow the 2.3 Building the server chapter from tracy.pdf manual in the Tracy-0.7.6.7z archive and build the Tracy server by your own. (On Linux, here is a good reference -Profiling with Tracy - IREE)
3. Run a sample
Run a sample you want to test.
In the Tracy server, press Connect button to start profiling