For both GLib and GIO. (GObject, GIRepository and GModule don’t have any
platform specific APIs.)
This is needed for two reasons:
* If the same GIR file is shipped on multiple platforms, it has no way
to conditionally define/not-define an API based on the platform (like
an `#ifdef` in a C header). So we either end up shipping differing
GIR APIs on different platforms, or shipping a GIR file which
declares APIs which aren’t resolvable by `dlopen()` on certain
platforms, and will cause a language runtime error.
* The API reference documentation is now generated from the GIR, and
similar problems are present there: if the GIR contains different
symbols depending on the platform, there is no way to generate API
documentation for the union of all of them.
The fix is to ensure that there are no conditional symbols in a GIR, by
splitting out the platform specific symbols into platform specific GIR
files. Platform specific documentation can then be generated from these,
in addition to the main, platform agnostic, documentation.
The documentation changes will following in a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Maintain them in separate lists within `meson.build`. This makes no
functional difference at the moment, but will be used in an upcoming
commit to generate separate GIR files per platform.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
There was no obvious logical need to list the `GAppInfo` subclass
sources separately in the build. It makes more sense to add them to the
platform-specific source lists, since they are platform specific.
This will be used in an upcoming commit which generates
platform-specific GIR files, so needs the full platform-specific lists
of sources.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
`GFileDescriptorBased` is in `gio-unix-2.0` rather than `gio-2.0`, so
its types shouldn’t be declared in a header belonging to the latter.
This hasn’t been a problem previously because C is fine with that. But
upcoming commits are going to split the introspection scanning for
`gio-2.0` and `gio-unix-2.0`, and the introspection scanner is a little
more picky about declarations not being spread all over the place.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Seems no point in keeping them separate. It doesn’t seem to matter if
they contain entries which are unused for a particular docs build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This reverts commit 50d432c77b.
The platform-specific headers of GLib and Gio are now introspected
separately, so the documentation for them can be built separately, and
this workaround is no longer needed.
Helps: #3037
It was causing a build failure on some platforms:
```
In file included from ../girepository/gthash.c:29:
In file included from ../girepository/gitypelib-internal.h:30:
../girepository/girepository-private.h:26:10: fatal error: 'ffi.h' file not found
#include <ffi.h>
^~~~~~~
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Instead, add a method on `GIRegisteredTypeInfo` which indicates whether
the registered type is a boxed type. This will return true for
`GIStructInfo` and `GIUnionInfo` instances which are boxed (not all
structs and unions are).
This makes `GIBoxedInfo` redundant, and it’ll be dropped in a following
commit.
---
There are several different things which typelibs need to be able to
represent:
1. Plain old datatype (POD) structs
2. POD unions
3. Structs with a copy func and/or free func
4. Unions with a copy func and/or free func
5. Structs which are the ‘GType struct’ for an object or interface (i.e.
the class or instance or interface struct)
6. Structs with a copy func and free func *and* boxed GType
7. Unions with a copy func and free func *and* boxed GType
8. Boxed GTypes which represent something other than a struct or union
So there’s a lot going on here. In commit
e28078c70cbf4a57c7dbd39626f43f9bd2674145, a lot of this was reworked,
and support was added for boxed unions and boxed ‘others’ (the last item
on the list above).
Since then, support for boxed types other than structs seems to have
atrophied a bit, and the whole lot has got a bit confusing.
It was perhaps less confusing when all the `GIBaseInfo` subclasses were
actually aliases of each other, but now they have subtype relationships,
the position of `GIBoxedInfo` in that type hierarchy has become unclear.
How is it related to `GIStructInfo`, `GIUnionInfo` and
`GIRegisteredTypeInfo`?
Since a boxed type is necessarily a `GIRegisteredTypeInfo`, and the
methods of `GIRegisteredTypeInfo` are all written to allow a `GType` to
be optional, so that `GIStructInfo` and `GIUnionInfo` can safely derive
from it and still be used to represent plain old datatypes without
`GType`s, it makes sense to add a method to `GIRegisteredTypeInfo` to
indicate that the registered type is derived from `G_TYPE_BOXED`.
Accordingly, the things above are now represented in libgirepository’s
type system as:
1. `GIStructInfo` instance, `GIRegisteredTypeInfo` methods return no
`GType` info
2. `GIUnionInfo` instance similarly
3. `GIStructInfo` instance, `GIRegisteredTypeInfo` methods return no
`GType` info, `gi_struct_info_get_{copy,free}_function_name()` return
non-`NULL` values
4. `GIUnionInfo` instance similarly
5. `GIStructInfo` instance, `GIRegisteredTypeInfo` methods return no
`GType` info, `gi_struct_info_is_gtype_struct()` returns true
6. `GIStructInfo` instance, `GIRegisteredTypeInfo` methods return valid
`GType` information, `gi_registered_type_info_is_boxed()` returns
true, `gi_struct_info_get_{copy,free}_function_name()` return
`NULL` values (because the copy/free functions are hidden inside the
boxed type registration at runtime)
7. `GIUnionInfo` instance similarly
8. Not representable, but could be represented in future by re-adding a
`GIBoxedInfo` type which derives from `GIRegisteredTypeInfo` and is
used solely for boxed ‘other’ types, *not* boxed structs or unions
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3245
When creating `GIBaseInfo` instances from binary blobs, so far the code
has used an undocumented implicit conversion from one enum type to the
other. That’s a bit nasty, as it means the two enum types need to be
kept in sync (without that need being documented).
Introduce an explicit conversion function to make things more explicit.
Currently it does nothing, but in an upcoming commit it will be used to
deprecate a blob type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3245
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
