We don't need to dynamically link against libsysprof for sysprof-cli as
we can do the same thing that sysprof-agent does. In fact, we can probably
even make sysprof-cli wrap sysprof-agent in the future (or be the same
binary that looks at it's argv[0]).
If we have tooling that can toggle -finstrument-functions, Builder for
example, then we'd be able to use an LD_PRELOAD to inject the various
function callbacks to record samples.
I dont think we want to use the sample frame type for this though. We
really want something focused on tracing instead and visualize it a bit
differently than the stack trace visualizer.
This means we don't install org.gnome.Sysprof.svg anymore when building
with -Ddevelopment=true (and vice versa). We do use org.gnome.Sysprof.svg
from libsysprof-ui, but that embeds the appropriate resources.
The agent is statically linked so that it doesn't require using a properly
working libsysprof to be installed. This ensures that it continues to build
properly in that case so it can be used from org.gnome.Sdk.
This also builds the agent statically with libsysprof_static_dep since
we'd need that to avoid installing libsysprof when that isn't wanted.
It also ensures the LD_PRELOAD libraries are installed for use by the
agent.
This is a program that can be communicated with over private D-Bus using
pipes to control a process. It is useful in an automated fashion from
tooling such as Builder.
This allows, when installed into SDKs like GNOMEs, to profile from inside
the container rather than from the outside. Such is useful when you need
to ensure you have access to LD_PRELOAD/etc within the context.
This is useful so that we can know when a subprocess has spawned by the
profiler in tooling which allows sysprof to spawn a process and monitor
said process. Additionally, we need to know when it exits so that we can
be correct in when we can call get_if_exited() from tooling.
