Just skip the test if the unix transport isn’t supported. This means we
get better compilation coverage, and more explicit TAP output saying
that the test is being skipped on unsupported platforms.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The specification doesn’t explicitly say this, but it doesn’t say
otherwise, and it would be pretty weird to have an empty transport name
or key.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
No need for the `meaningless` label and some unreachable if-branches.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is not new; all of its methods have been deprecated for a long
time. Make the deprecation more obvious, however, by marking the whole
section as deprecated.
Note that GArray can’t *quite* do everything that GValueArray could.
See #1069 for work to fix this. This documentation block can be updated
again once that’s fixed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It would be nice if docs.c eventually went away — it’s more maintainable
for documentation comments to be next to the definition of the symbols
they document.
Move a few from docs.c, based on what I’ve been modifying recently.
The documentation comments are unchanged apart from fixing an argument
name for G_ALIGNOF.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
While gtk-doc can currently detect a link to a symbol which has been
pluralised by adding ‘s’, it can’t detect when ‘es’ is added. While
that’s being fixed, reword the documentation so the links are generated
correctly anyway.
gtk-doc fix here: https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/22
Signed-off-by: Philip Withnall <withnall@endlessm.com>
As pointed out by gtk-doc, these are all symbols which have been marked
as deprecated, but which aren’t protected by a deprecation guard. We
can’t use G_DEPRECATED_IN_* for them, as they are all non-function
symbols. Instead, wrap them in #ifndef G_DISABLE_DEPRECATED.
In some cases, we also need to wrap one or two functions which use the
deprecated types in G_DISABLE_DEPRECATED too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
dep-list.c isn’t generated, but contains non-documentation gtk-doc-style
comments which are probably better left in place, since the code is
partially external to GLib.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In cross-compilation environments the runtime check isn't possible so it is up
to the builder to seed the cross file, but we can definitely state that strlcpy
doesn't exist with a build test.
It isn't always obvious how and where to use these. Where possible I've
chosen real examples from GLib, preferring simple examples that
developers considering using these macros have hopefully already seen.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If using the --interface-info-{body,header} options to gdbus-codegen,
and the first interface to be outputted has no methods, but does have
properties or signals, an uninitialised variable would be used for the
property/signal ‘since’ values.
In other situations, the ‘since’ value for a prior method would have
been incorrectly used for the properties/signals.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
