With this change, sysprof can be consumed as a subproject without
making any changes to the build files of a project. All you need to do
is provide a wrap file with a `[provide]` section:
https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section
This is also necessary because otherwise projects need to hard-code
the subproject name, which might be `sysprof` when using `wrap-git` or
`sysprof-3.46.0` when using `wrap-file` (to build from a release
tarball). This can cause conflicts between different subprojects that
consume sysprof differently.
Other projects like glib, cairo, pango, etc already do this.
This code uses the hashtable directly to avoid the overhead of calling
the path which creates ProcessInfo entries. So we need to also handle
the chance the lookaside is NULL.
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.
This isn't exactly ideal in our use, but it's transitionary so that we
can get rid of the EggThreeGrid which is very out of place in a libadwaita
world.
