It gives nowhere near full coverage, but it’s something we can build on
in future.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3158
Helps: #2950
Modify all the similar Python test wrappers to set
`G_DEBUG=fatal-warnings` in the environment of the program being tested,
so we can catch unexpected warnings/criticals.
Adding this because I noticed it was missing, not because I noticed a
warning/critical was being ignored.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
If the help output is explicitly requested by the user, it’s
conventional for it to be printed to stdout rather than stderr.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Store their details in an array which can be iterated over instead.
This introduces no functional changes, just a cleanup which will allow
following commits to be neater.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
If she socket is dispatched at exactly the previously set ready time,
it should already be considered to have timed out. This can easily
happen in practice when using a low resolution timer.
This fixes a test failure on GNU/Hurd, see
https://gitlab.gnome.org/GNOME/glib/-/issues/3148
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
The test only needs a unidirectional channel, and a pipe is sufficient
for that.
This may simplify things when running the test on Hurd; see
https://gitlab.gnome.org/GNOME/glib/-/issues/3148#note_1874198.
Additionally, set `O_NONBLOCK` on the pipe since the test seems to
expect that partial writes will succeed and that writes to a full buffer
will fail rather than block.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
Various parts of the build (such as `objectmanager-rst-gen`) depend on
running `gdbus-codegen` after it’s been built, but they currently only
encode a dependency to the main codegen Python file and not the
supporting files. This can cause `gdbus-codegen` to fail with an
`ImportError` if the build races so that `objectmanager-rst-gen` is
built before the codegen supporting files.
Example failure here: https://gitlab.gnome.org/pwithnall/glib/-/jobs/3266471
```
FAILED: gio/tests/gdbus-object-manager-example/objectmanager-rst-gen-org.gtk.GDBus.Example.ObjectManager.Animal.rst gio/tests/gdbus-object-manager-example/objectmanager-rst-gen-org.gtk.GDBus.Example.ObjectManager.Cat.rst
/usr/bin/python3 gio/gdbus-2.0/codegen/gdbus-codegen --interface-prefix org.gtk.GDBus.Example.ObjectManager. --generate-rst objectmanager-rst-gen --output-directory gio/tests/gdbus-object-manager-example ../gio/tests/gdbus-object-manager-example/gdbus-example-objectmanager.xml
Traceback (most recent call last):
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/gdbus-codegen", line 53, in <module>
from codegen import codegen_main
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/codegen_main.py", line 29, in <module>
from . import dbustypes
File "/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/dbustypes.py", line 22, in <module>
from . import utils
ImportError: cannot import name 'utils' from 'codegen' (/builds/pwithnall/glib/_build/gio/gdbus-2.0/codegen/__init__.py)
```
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
All the calls to `usage()` are immediately followed by a `return` from
`main()` which sets an appropriate exit status.
Calling `exit()` early means that running `gio --help` returns exit
status 1, which is incorrect — it should (by convention) return 0.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Depending on the operating system, /bin/sh might either be bash (for
example on Fedora or Arch) or dash (for example on Debian or Ubuntu)
or some other POSIX shell.
When bash is asked to run a simple command with no shell keywords or
metacharacters, like this one, it replaces itself with the program
via execve(), but dash does not have that optimization and treats it
like any other program invocation in a larger script: it will fork,
exec the program in the child, and wait for the child in the parent.
This seems like it conflicts with sleep_and_kill() assuming that it can
use the subprocess's process ID as the sleep(1) process ID. Specifically,
if it sends SIGKILL, it will go to the sh(1) process and not the sleep(1)
child, which could result in the sh(1) process being terminated and
its sleep(1) child being leaked.
To get the bash-like behaviour portably, explicitly use the exec builtin
to instruct the shell to replace itself with sleep(1), so that the
process ID previously used for the shell becomes the process ID of the
sleep process.
This appears to resolve an intermittent hang and test timeout on Debian
machines (especially slower ones), although I'm not 100% clear on the
mechanics of how it happens.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3157
Signed-off-by: Simon McVittie <smcv@collabora.com>
`test-generated.txt` is listed in `test.gresource.xml`, so it needs to
be specified as a dependency in the `custom_target()` which uses
`test.gresource.xml`.
Fixes intermittent build failures like:
```
FAILED: gio/tests/test.gresource
/builds/GNOME/glib/_build/gio/glib-compile-resources --compiler=gcc --target=gio/tests/test.gresource --sourcedir=/builds/GNOME/glib/gio/tests --sourcedir=/builds/GNOME/glib/_build/gio/tests --internal ../gio/tests/test.gresource.xml
../gio/tests/test.gresource.xml: Failed to locate test-generated.txt in any source directory.
```
See !3671 and #3163.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
This reverts commit 0b9900e4e7.
The dependency was added in the wrong place: `test-generated.txt` is
needed when compiling `test.gresource`, not when compiling the test
which ultimately uses that gresource.
See !3671 and #3163.
The PTRACE_O_EXITKILL symbol in sys/ptrace.h is an enum member, not
a macro. The #ifdef check added to the GSubprocess test-case in
272ec5dbca will not detect it.
Use cc.has_header_symbol() to properly detect it. According to the
documentation: "Symbols here include function, variable, #define,
type definition, etc.".
Fixes: 272ec5dbca
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3156
On CHERI-enabled systems we use uintptr_t as the underlying storage for
GType and therefore casting to gsize strips the upper bits from a pointer.
Fix this by casting via uintptr_t instead and introduce a new set of
macros to convert between GType and pointers.
It needs to be in a separate page because there isn’t actually a
`GFileAttribute` type.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
Move it to the struct docs, although again this is a little suspect
because there is actually no `GDBusAddress` struct/type.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
This might not work, as `GContentType` isn’t actually a defined type
(content types are just strings). It would be a bit weird to create a
separate page for content types, though, as the functions handling them
are very method-like and feel like they should be grouped together like
methods of a class.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3037
Currently, the introspection data for GLib and its sub-libraries is
generated by gobject-introspection, to avoid the cyclic dependency
between the two projects.
Since gobject-introspection is generally available on installed systems,
we can check for its presence, and generate the introspection data
directly from GLib.
This does introduce a cyclic dependency, which is why it's possible to
build GLib without introspection, then build gobject-introspection, and
finally rebuild GLib.
By having introspection data available during the GLib build, we can do
things like generating documentation; validating newly added API; and
close the loop between adding new API and it becoming available to non-C
consumers of the C ABI (i.e. language bindings).
If `update-desktop-database` or `update-mime-database` are not
installed, there are a few `GAppInfo` methods for modifying file
associations which will print a `g_warning()` when called. Something
like:
```
GLib-GIO-FATAL-WARNING: Failed to execute child process ‘update-desktop-database’ (No such file or directory)
```
(Example: https://gitlab.gnome.org/zamaudio/glib/-/jobs/3190053)
This will cause the appinfo/associations test to fail, as warnings are
fatal.
If that’s going to happen, skip the test. We can’t hard-depend on these
tools as they are external to GLib and only needed for a few operations.
Instead we have a soft runtime dependency on them; that should be
reflected in the tests.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3148
Commit f6c40b1d fixed libelf detection on FreeBSD (where the library has
no pkg-config file and needs to be found via `find_library()`), but
broke `-Dlibelf=disabled` on Linux, as `get_option('libelf')` was no
longer checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3120
