This is quite gross, but it looks like the whole content-type code on
Windows is similar. Pass test_subtype.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
We are matching `<parameter>` as well as `<para>`, and we
end up with broken XML in case the (expanded) description
starts with `<parameter>`.
Fixes: #2601
This allows the controller to explicitly be removed from the bus, in a
way that allows the caller to synchronise with it and know that all
other references to the controller should have been dropped (i.e. after
this method returns, there should be no in-flight D-Bus calls still
holding a reference to the object).
This is needed to be able to guarantee finalisation of the controller in
unit tests (and comparable real-world situations).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
The resources data is generated for both GCC and MSVC toolchains, even
though we know beforehand which toolchain we're going to compile it for.
By dropping the data duplication we make the generated resources file
faster to compile, especially when dealing with large embedded data,
instead of relying on the C pre-processor to walk the whole file and
discard the branch we're not using.
If `GDebugControllerDBus` remains as the only, or default,
implementation of `GDebugController`, `dup_default()` cannot work.
`GDebugControllerDBus` requires a `GDBusConnection` at construction
time, which the `GIOModule` construction code can’t provide it.
Either we use a default D-Bus connection (but which one? and how would
it be changed by the user later if it was the wrong one?), or delegate
singleton handling of the `GDebugController` to the user.
The latter approach seems more flexible.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
On Windows, dbus is launched by spawning the gdbus.exe executable on
demand from the gio module. When linked dynamically, the executable
path is guessed relatively to the gio DLL path. But when linked
statically, the only reference path available is the current
executable path. In this case, gdbus.exe is not necessarily in the same
folder as the current executable.
This patch solves the issue using the same algorithm as the one used
with process spawning in glib core source code two commits above.
This is intended to provide a uniform interface for controlling whether
the debug output from an application (or service) is emitted, typically
to journald, but actually to wherever the application chooses to output
it.
The main implementation of `GDebugController` is `GDebugControllerDBus`,
which is intended to be used on Linux. Other implementations may be
added in future for other platforms, or larger applications may want to
provide their own implementation which integrates with their ecosystem.
The `GDebugControllerDBus` implementation exposes a D-Bus interface at
`/org/gtk/Debugging` with a method to enable or disable debug
output at runtime.
This could be used by external harnesses, such as GNOME Builder or
systemd, to give a uniform way to get debug output from an application.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1190
As with the previous commit, this isn’t needed for GLib’s tests to work
correctly, but is probably needed in other projects which might be
tempted to copy and paste the Meson tooling from GLib.
Inspired by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4330
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This isn’t needed to make the tests any better (it doesn’t really affect
them), but is probably needed for anyone who copies this Meson code in
order to add `glib-compile-resources` support to their project. It’s
pretty unlikely that someone would want to compile *and export* a
resource from a shared library.
Inspired by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4334
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Credentials are often used to check peer processes details.
With AF_UNIX sockets on Windows, SIO_AF_UNIX_GETPEERPID can
be used to retrive the peer PID.
We will probably introduce more advanced mechanisms later on, though,
but I am not a Windows API expert.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
On !UNIX, return an error for send_fd() & receive_fd().
(the unixfdmessage unit is not compiled on !UNIX)
The header is installed under the common GIO include directory.
Ensure G_TYPE_UNIX_CONNECTION is registered on all platforms.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
