It’s actually a factory method rather than a constructor, since
`GIBaseInfo` is abstract, but despite that, changing the name so it sits
inside the `GIBaseInfo` class makes sense. There is no `GIInfo` type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It’s a separate type, so it would be less confusing if it were in its
own file.
This doesn’t change any API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Even though we expose member access as size_t, a GI info blob can
typically just access to an a number of values that is never bigger
than uint16_t, as that's how the typelib is defined (cfr. typelib
internal header blob sizes and n_* elements).
So let's avoid this to happen by adding a check.
We used to use unsigned values, while they should be big enough to old
the data we're handling here, it's cleaner and clearer if we use size_t
as type for such values, as it makes straight forward to understand what
a value should contain. It also makes these values more future proof.
Review and update the documentation, making sure it’s complete,
formatted in gi-docgen format, and has all appropriate GIR annotations
and `Since:` lines.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This adds more type safety to libgirepository, and allows
differentiating the `GIBaseInfo` derived types using the type system.
Two new derived types had to be added (previously they were just a
collection of helper methods which worked directly on a `GIBaseInfo` and
didn’t check types): `GICallbackInfo` and `GIUnresolvedInfo`.
Further cleanups and refactoring might be needed on this, but the core
of libgirepository now uses `GTypeInstance` and appears to still work
(it’s difficult to be entirely sure because there are no unit tests
yet).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than a mix of structs being in `GI` and their methods being in
`g_`.
We’ve chosen not to use the `g_` namespace because a number of the
libgirepository class names are quite generic, so we’d end up with
confusing symbols like `GScopeType` and `GArgument`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Make sure that each C file in `girepository/` includes its corresponding
header file (if such a file exists).
This ensures that the first declaration the compiler sees for each
function contains the symbol visibility macros. This fixes symbol export
(`dllexport`) on Windows platforms.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
The pkg-config file sets the include directory to the level above
`girepository/`, just like with GIO, GObject and GModule.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
Add the SPDX license runes to all the files which have an obvious
copyright header already. This is a mechanical edit.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
