Make possible to run glib processes where all the GMessage's output is
written to stderr.
By default we do it only for log levels greater or equal than warning,
but in some cases we may want to send all the glib logging to stderr.
This was possible to do programmatically, but there might be still cases
in which this has to be setup in the environment.
So, add support for a new environment variable, without changing the
ability for a program to set this to another value (at early start).
Extra lines must be prepended with `#` which g_test_message() does for
us. Note that lines after "Bail out" are ignored, so we print
stdout/stderr before.
Only use g_test_log() because it will prepend `#` to log messages when
using TAP protocol. Meson >=1.0 rightfully prints a warning when using
TAP protocol and stdout contains non-comment unknown TAP command.
Sadly meson 60 doesn't support parsing TAP 14 subtests properly, so it would
fail.
So temporary go back to the previous logic in a simple way so that this
commit can be reverted quickly when we can use a newer meson version.
Instead of just commenting all the output of sub-processes we can just use
the TAP 14 syntax for subtests, by using 4-spaces to indent the subtests
output.
This may not work perfectly when there are sub-process that may write
output mixed with the parent, but it should be enough to expose the
hierarchy.
If a gtest process is run as a child of another process, we should not print
the TAP output in plain mode or we'll break the parent results.
We can instead just comment their output so that it gets ignored by TAP
parsers.
Do not write it in multiple lines, to ensure it's going to be written
all together, and nothing else could be written in the middle.
Also optimize a bit the code.
We used to send the test log to stderr in pieces, but this could be
problematic when running multiple tests in parallel, so let's just prepare
the string in pieces and write it all at once.
In some cases if verbose output was enabled we were using wrong output
format in TAP mode, so let's fix these cases and run the 'testing' test
case in --verbose mode to ensure we won't regress.
When running multiple tests in parallel using meson, the output could be
mixed and if we write the TAP reports in multiple steps the output could
be mangled together with other results.
An example is: https://gitlab.gnome.org/3v1n0/glib/-/jobs/2507620
Where we have:
ok 5 /cancellable/poll-fd# GLib-GIO-DEBUG: Collecting capable appnames: 0ms
# Allocating hashtables:...... 0ms
# Reading capable apps: 63ms
# Reading URL associations:... 0ms
# Reading extension assocs: 78ms
# Reading exe-only apps:...... 47ms
# Reading classes: 312ms
# Reading UWP apps: 47ms
# Postprocessing:..............16ms
# TOTAL: 563ms
# SKIP Platform not supported
Leading to a clear TAP parsing error
This is not required, but meson may warn about in future versions, so it's
safer to define it.
However, we must be sure that we only expose it once and in the root binary
if a test file launches another subprocess test file.
To avoid this, we set an environment variable at test init, so that it can
be inherited by children.
It's not the best solution, but for sure the best-effort one without having
to change gtest arguments and called binaries.
Non mentioning a version was considered as assuming we were using TAP
version 12, while no version earlier than 13 can be specified
explicitly so let's use it.
See: https://testanything.org/tap-specification.html
And: https://testanything.org/tap-version-13-specification.html
As per meson default, the project name is a suite per se that is always
added to a test, so running `meson test --suite=glib` is the same as not
passing the `--suite` argument at all, and so making all the tests to run.
To be able to only run the *glib* tests without using the `--no-suite` args,
add a `core` suite that only targets the glib folder tests.
In all these cases we don't really care about running the test file,
while building and basic execution it is relevant.
Also they don't support TAP at all.
Meson supports tap protocol results parsing, allowing us to track better
the tests that are running (and the ones that are actually skipped) without
manually parsing the test output.
However this also implies that using the verbose mode for a test doesn't
show its output by default (unless there are failures).
`memcpy(NULL, ., n)` and `memcpy(., NULL, n)` are undefined behaviour,
even if *n* is zero.
When len is 0 here, callers are allowed to pass in null data, and
GPtrArray also does not guarantee to have allocated rarray->pdata yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
ptr_array_new(len, ., TRUE) ensures that there are at least len+1
elements in pdata, and that pdata[0] is null, but leaves the rest of
pdata uninitialized. After copying the array data into pdata[1] to
pdata[len-1] inclusive, we still need to make sure pdata[len] is a
null terminator.
Note that if len is 0, then pdata is not guaranteed to be non-null. If
it's null, then we can't add null-termination to it until its size
is updated.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2877
Signed-off-by: Simon McVittie <smcv@collabora.com>
This has historically failed on Debian autobuilders, and as a result we
have had a patch for a long time that turned a failure here into a
g_test_skip(). It's not clear whether this still happens, so I'm now
assessing whether the patch can be dropped; but if the prlimit() call
can fail for whatever reason, it would be useful for the error message
to say what limit we were trying to set.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commit 1422e5f81241650c634413911e92d23495692545. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
This reverts commit da7a31a052614edd2cc87518585ff371cbb0f204. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
The gobject-introspection build goes through the GLib types when
generating the introspection data for GLib, but it does not include
glib-object.h, otherwise all GObject symbols would end up inside the
GLib namespace. This means we need to import the gobject-visibility.h
header inside glib-types.h. Since the header is guarded by a once
pragma, it doesn't really affect any legitimate user of the C API.
We cannot use `gvisibility_h` for different visibility header files; you
never know when you're going to refer to the variable again, and
projects might end up needing to retrieve the variable contents—like,
for instance, gobject-introspection using glib as a subproject.
Historically GPtrArray made possible to compare pointers of pointers values
that it holds, however this is inconvenient in most cases as it requires
wrapper functions and not friendly castings.
So, add two functions that allow to perform the comparisons between the
pointer values that a GPtrArray holds following the same syntax that we
share everywhere in the codebase.
