While it’s an internal API which `girwriter.c` has access to, it’s not
available inside `libgirepository-internals.so`. This wasn’t spotted
before commit 343027d5d landed because none of the existing users of
`libgirepository-internals.so` use the relevant code in `girwriter.c`,
so it got compiled out (`libgirepository-internals.so` is statically
linked and can be optimised like this).
Now that `gi-decompile-repository` uses the relevant code from
`girwriter.c`, the problem is obvious and `gi-decompile-repository`
fails to link.
Fix that by no longer using `gi_base_info_get_info_type()` in
`girwriter.c`. These are changes which would have eventually been made
anyway in issue #3253.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3253
`--version` is conventionally used to find the version of the program
itself. While that’s not currently implemented in
`gi-inspect-repository`, let’s not box ourselves into a corner.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Update the code to the latest standards and to use girepository-2.0
after it’s been imported to this repository.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Update the code to the latest standards and to use girepository-2.0
after it’s been imported to this repository.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rename them to `gi-decompile-repository` and `gi-inspect-repository` to
match the existing `gi-compile-repository`. The names have to differ
from those used in girepository-1.0 to avoid collisions.
‘generate’ has been changed to ‘decompile’ because it does the inverse
of what `gi-compile-repository` does: it converts a typelib to a GIR
file. ‘generate’ never really made much sense for this anyway — it’s
almost a synonym of ‘compile’.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This reverts commit 94273b0ebf.
Meson 1.2.0 contains a fix for the underlying issue (in commit
bd3d2cf91894b1f91128011b2cf56a5bd2c326ae), and we now depend on 1.2.0.
So the workaround is no longer needed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
GLib is used a subproject with GObject Introspection and overriding
this binary breaks that usage. For now we will make overriding the
binary conditional until Meson is updated to handle the binary changes.
In the project from which this copy of cmph was forked, this was fixed
in version 2.0.2 by commit
bbf77c63c9/
Signed-off-by: Simon McVittie <smcv@collabora.com>
The docs for this should match the docs for `g_unix_open_pipe()`, which
it calls.
Inspired by !3911.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Using FD_CLOEXEC here is now deprecated. Keep exactly one call with
FD_CLOEXEC, in test_pipe_fd_cloexec().
Signed-off-by: Simon McVittie <smcv@collabora.com>
The copy of this function that moved to glib-unix.c still needs to
implement the fdwalk-style interface, but this copy does not, allowing
us to turn it into a very simple syscall wrapper. Its remaining callers
never check for errors, and it never failed anyway, so remove the
returned value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These are the same as Linux `close_range (lowfd, ~0U, 0)` and
`close_range (lowfd, ~0U, CLOSE_RANGE_CLOEXEC)`, but portable.
Unlike some implementations of BSD closefrom(3), they are
async-signal-safe.
The implementations were moved from the GSpawn code, which already
needs all of this functionality anyway, with the exception of
set_cloexec() which was copied (leading to some minor duplication,
but it's very simple).
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3247
Signed-off-by: Simon McVittie <smcv@collabora.com>
They don’t need to be listed there in order to be built, and doing so
just means they get pulled into the `g-ir-scanner` command for building
`GLib-2.0.gir` and their contents end up being listed as public
introspectable API, which is not what we want.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3231
The symbols still have to be exported from the library (since they’re
called from unit tests), but there was never any reason for them to be
in a public header.
This means they now disappear from `Gio-2.0.gir`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3231
This property is supposed to be used by authors of applications that use GAppliaction to output the version by --version flag or otherwise if a version is needed.
Closes#3198
Signed-off-by: Maxim Moskalets <Maxim.Moskalets@kaspersky.com>
These can then be used by a parent project if GLib is used as a Meson
subproject.
In particular, GJS wants to use `GLib-2.0.typelib`
from GLib-as-a-subproject, but doesn’t want to hardcode the path to it
inside the GLib builddir.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3244
Various distributions (mainly RPM based so far) make use of automatic
dependencies extracted from typelib files (they can require other typelibs
and also shared libraries)
Current features
* Print used shared libraries
* Print used typelib dependencies
Based-on-patch-by: Dominique Leuenberger <dimstar@opensuse.org>
Reference: https://bugzilla.gnome.org/show_bug.cgi?id=665672
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Dominique Leuenberger <dimstar@opensuse.org>
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
Take a GError * for typelib loading code, validate the header. This
fixes bizarre errors from gjs where g_irepository_require would happily
load old typelibs.
