2005-05-13 Matthias Clasen <mclasen@redhat.com>
* tests/*: Update testcases.
* src/generate.c (write_callable_info): Don't forget to
write transfer and null-ok attributes for return types
and parameters.
* src/girepository.h:
* src/ginfo.c (g_callable_info_may_return_null):
New function to find out if a function may return NULL.
2005-05-09 Matthias Clasen <mclasen@redhat.com>
* gidl.dtd: Clean up handling of names. All elements
have a "name", only the elements corresponding to
actual callable functions (function, method, constructor),
have an additional "symbol" attribute holding the
dlsym()-able function name.
* src/generate.c: Adapt to generate xml matching the
new dtd.
* src/gidlparser.c:
* src/gidlnode.c: Adapt to parse the new dtd.
* tests/*.test: Adjust to the new dtd.
* metadata-format.txt:
* src/gmetadata.h: Remove the short_name field
from the ValueBlob.
* src/gmetadata.c: Shrink size of ValueBlob to 12.
* src/girepository.h:
* src/ginfo.c (g_value_info_get_short_name): Removed
Eventually, we want to move to using `GType` directly for everything,
since `GIBaseInfo` and its subclasses are all using `GTypeInstance`.
However, that requires quite a lot of changes and we’re about to hit the
API freeze.
So do the smallest set of changes possible to remove `GIInfoType` and
related functions from the public API, which gives us freedom to make
more changes later without breaking API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
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
This is needed because `GITypelib` is exposed in the public
libgirepository API, so needs to be introspectable.
This should fix a couple of warnings about `gi_repository_require()` and
related APIs not being introspectable as they return an unintrospectable
type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Since `GITypelib` is exposed in the public libgirepository API, it needs
to be a boxed type. So we either need to add a `copy` method to mirror
the existing `free` method, or switch to refcounting. The latter option
seems better, since a `GITypelib` contains internal state about open
`GModule`s and the semantics for copying that would be potentially
complex.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This makes them consistent with the other getter methods in
`GIRepository` which return lists/arrays. It’s useful to return the
length, as that means the caller doesn’t have to work it out by
iterating over the entire array.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This effectively reverts commit 0910e2f6ad. I thought that `GIInfoType`
was decoupled from `GITypelibBlobType`, but it turns out that
`girepository.c` calls `gi_info_new_full()` with blob types, implicitly
converting them to info types.
This was causing anything with a type higher than the `INVALID_0` value
to be loaded as the wrong type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Otherwise there’s no obvious suitable return value to return when the
union is *not* discriminated.
This is an API break, but libgirepository has not been in a stable
release yet, so that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Fix the declaration and documentation of
`gi_object_info_find_method_using_interfaces()` and
`gi_object_info_find_vfunc_using_interfaces()`. The documentation was
wrong when I wrote it: the value returned is the object or interface
which declares the method or vfunc, not the one which implements it.
The returned declarer info may be a `GIObjectInfo` or a
`GIInterfaceInfo`. Since those two types have no subtype relation
between them, the return type has to be changed to `GIBaseInfo`. Using
`GIObjectInfo` would have been fine in girepository-1.0 because all
`*Info` types were aliases of each other — but since the move to
`GTypeInstance` this is no longer true.
A unit test will be in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3246
So that it matches `gi_arg_info_get_type_info()`. We can’t use
`gi_arg_info_get_type()` because that collides with the `GType` getter
for the type.
Spotted by Philip Chimento.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3243
GI_IS_REGISTERED_TYPE_INFO() wasn't working because it was actually
defined to be the same as GI_IS_OBJECT_INFO().
Add some desultory type-checking assertions to the repository tests.
gi_repository_enumerate_versions() was missing a type check of the
instance parameter. This helps catch mistakes when porting from
girepository 1.x where the parameter was allowed to be null.
There are a handful of APIs in libgirepository which are used on
performance-sensitive code paths in language bindings (such as looking
at arguments when doing function calls). Historically libgirepository
has provided a stack-allocated variant for them, which avoids returning
a newly allocated `GIBaseInfo`. Since moving to glib.git and porting to
`GTypeInstance`, that stack allocated version has been broken.
This commit fixes it, by exposing obfuscated stack allocatable versions
of `GITypeInfo` and `GIArgInfo`, which are the two `GIBaseInfo`
subtypes which can be returned by the stack allocation functions.
The commit includes unit tests for them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3217
Adapt gi-compile-repository sources to compile against the updated
libgirepository that is included with GLib.
This also renames "g-ir-compiler" to "gi-compile-repository" to avoid
overwriting the existing binary and to simplify the binary name going
forward.
This was introduced by me in commit
1eec66c898, as the ownership transfer
semantics of `gi_typelib_new_from_mapped_file()` were not blatant.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3237
To enable tests which depend on libgirepository's GIR and typelib,
we need to refactor the order we're currently building these items.
We can also move everything under girepository/ to cleanup the
top-level.
We now only support creating `GIRepository` instances as normal
GObjects, not as a global singleton. This makes the semantics of the
class a bit more standard and, in particular, makes it easier to ensure
that everything is freed when we’re done with libgirepository. This is
particularly useful for unit testing, but should also be useful when
unloading modules from bindings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than them being set and stored globally, make them members of
`GIRepository`. This helps us move away from the concept of a global
singleton `GIRepository`.
This is slightly complicated by the fact that the library paths are
needed within the module loading code in `GITypelib`, but at that point
the `GITypelib` doesn’t have access to its parent `GIRepository` to call
`gi_repository_get_library_path()`, so we have to cache them in
`typelib->library_paths`.
It also means that it’s no longer possible to retrieve the ‘unset’ paths
from the globals, so the test for that is removed from
`repository-search-paths.c`.
This commit makes some API breaks, but that’s OK because libgirepository
has not been in a stable release yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This means they’re implemented in the same file as the typelib search
path, so it’s easier to refactor the code.
This adds `gi_repository_get_library_path()` to expose the library path,
both publicly and to internal users in `gitypelib.c`. And unit tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GBytes` provides a way of handling const memory blobs, stolen memory
blobs, and mapped files. Rather than having `GITypelib` implement all of
those itself, just take a `GBytes` as input.
This is an API break, but libgirepository hasn’t been in a stable
release yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeUnion` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GIIrNodeEnum` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GIIrNodeField` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
This also includes some offset validity changes which were forgotten
from commit 515b3fc1dc.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeVFunc` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`class_closure` isn’t actually meaningfully set anywhere in the code yet
(there are FIXME comments), so I’m not sure of the best type for it. But
generally `unsigned` is more widely used than signed `int`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeType` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`g_strdup(NULL)` is guaranteed to return `NULL`, so there’s no need to
branch to handle that.
Add a stub private doc comment to hold a `(nullable)` annotation for
that argument, though, so that information isn’t lost.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Might as well move to a modern way of declaring GObjects. This means
that `GIRepository` is no longer derivable, but it would be a bit
unexpected if anyone was deriving from it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This is just for future reference for people reading the code in future.
I was going through and checking to see if any of them needed to be made
`const` (none of them did).
I did find a couple of memory leaks though; see the following commits.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
By shifting responsibility for ensuring that the lifetime of a
`GIRepository` always exceeds the lifetime of any of its `GIBaseInfo`s
to the user.
Keeping a weak ref from each `GIBaseInfo` to its `GIRepository` would be
too expensive (`GIBaseInfo`s are supposed to be cheap to create and
destroy, as they are used within function calls in language bindings).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3234
These flags were replaced by gi_callable_info_can_throw_error() in
girepository 1.x, but the flags were maintained for backwards
compatibility. No need to hold on to them in the 2.x API.
Note that these flags are also still maintained as separate bits in the
binary format, which is not changing. So, they still need to be read
from FunctionBlob and VFuncBlob if the bit is not set in SignatureBlob.
This is an API break for girepository 2.x, which is OK because the API
has never been released yet.
These tests come from gobject-introspection/tests/repository/. They
include whatever wasn't already covered by the existing tests.
The original files didn't have copyright information. That's been
reconstructed from commit messages of commits that added a test or a
substantial part of one.
This brings its naming more in line with modern GLib conventions.
This is an API break, but libgirepository is not API frozen yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This test case was originally written by Philip Chimento as a reproducer
for #3218. Let’s add it to the test suite to catch regressions in
stack-allocated `GIBaseInfo` handling.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
Most of the code for handling stack-allocated infos was correct, it was
just missing code to initialise the `GTypeInstance` member.
Since `GTypeInstance` isn’t really designed for stack allocation, this
is a little hacky — it requires setting up the member within
`GTypeInstance` manually. It works, though.
The externally visible consequence of this, though, is that
stack-allocated `GIBaseInfo`s now need to be cleared when they’re
finished being used. This allows the `GTypeClass` ref to be dropped.
All users of the stack-allocated APIs in libgirepository will need to
adapt to this change.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3218
This is one more step towards removing `GIInfoType`, and will also help
in a following commit which will directly make use of the `GType`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
As documented in the commit, the internal members of `GIBaseInfo` are
not reffed if the `GIBaseInfo` is stack-allocated, as the caller can be
relied on to ensure their lifetime exceeds that of the `GIBaseInfo`.
Make sure that’s actually reflected in the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
Make it take a `GITypeInfo` rather than a `GIBaseInfo`, because that’s
what it actually operates on.
This is an internal API, so this isn’t an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
This removes the gthash utility functions from the ABI, so link those
into their automated test statically.
Signed-off-by: Simon McVittie <smcv@collabora.com>
They get at least these `GIBaseInfo` subclasses up to a reasonable (but
not complete) coverage level.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
These follow GObject conventions, using `G_TYPE_CHECK_INSTANCE_CAST` to
cast to the given type, and potentially performing some runtime checks
of the type instance’s `GType` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3216
Just like is done with `g_object_{ref,unref}()`, make these functions
take a `void*` rather than a `GIBaseInfo*`, since they’ll most likely be
called with a type which is derived from `GIBaseInfo*` rather than a
`GIBaseInfo*` itself.
Add some runtime type checks to make up for lowering the compile time
type safety.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
This means they’re now using the `GType` type system rather than the old
`GIInfoType` type system. Given the preceding few commits, these two
systems should now be equivalent.
This makes the type handling more conventional and hence a bit simpler
for people to use if they have experience with GObject.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
There are various info types which were previously treated as subtypes
of `GIRegisteredTypeInfo` by the runtime type system in the old version
of libgirepository.
Change the new type tree to reflect that, making several types now be
subtypes of `GIRegisteredTypeInfo`, and making `GIRegisteredTypeInfo`
abstract.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
Boxed types are already represented within `GIInfoType`, so they should
have a `GType` representation as well.
In an upcoming commit, this will allow us to represent the subtype
relation between `GIBoxedInfo` and `GIRegisteredTypeInfo` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
Flag enums are already treated as a special kind of enum within
`GIInfoType`, so it would be tidier to give it its own `GType` too, with
a subtype relation to `GI_TYPE_ENUM_INFO`.
This will simplify implementing `GI_IS_ENUM_INFO` in a following commit
too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
Previously (and incorrectly), `GICallableInfo`, `GIFunctionInfo`,
`GICallbackInfo`, `GISignalInfo` and `GIVFuncInfo` were all derived
directly from `GIBaseInfo`. `GICallableInfo` is supposed to represent
all of the other types, though, so that type hierarchy was incorrect. It
dated from when all the types were aliases of each other and the type
management was done entirely at runtime.
Fix that by making the other four types derive from `GICallableInfo`,
and marking `GICallableInfo` as abstract.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
This doesn’t change the type hierarchy for now (i.e. it introduces no
functional changes), but it will allow us to add some intermediate types
into the `GIBaseInfo` hierarchy in an upcoming commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
This doesn’t change any of the flags for now (i.e. it introduces no
functional changes), but it will allow us to make some of the types
abstract in an upcoming commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
This makes `GIBaseInfo` and derived types more consistent with GObject
convention, and thus a bit more comfortable to use.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
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
Do this by tracking the state of the size/alignment calculations
separately, rather than bunging it into the `alignment` field using
magic values.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
As with previous commits, don’t use up half the return value space to
indicate an invalid index.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than mixing `-1` and valid indexes, split out the indication of
whether the type is an array with a length argument from the actual
index of the length argument.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`-1` isn’t part of `GIArrayType`, so it’s not particularly type safe to
return it from `gi_type_info_get_array_type()`. Instead, make it an
error to call that function on a type which isn’t an array type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Return information about whether the type is a fixed-size array
separately from the array size, which allows us to use the full `size_t`
for the array size.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Note that for alignments we should actually use size_t, but this would
imply some refactors since this value can be acually set to -1 in our
implementation.
So we use gssize for now, that at least on gcc is defined.
We are using various indexes types, but not always using the correct
sign or size, so let's adapt this to ensure we're consistent with the
values we're comparing with.
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.
We just do a safe s/gsize/size_t/ replacement here without doing any
changes to places in which different size of size_t and gsize may be
actually different and create troubles.
The "--code" option was removed years ago in d5b8d8d523c3bc26aa9fe6c364d3a17d325b55b6
so remove references to it from README and g-ir-compiler(1)
Remove the "--no-init" option from g-ir-compiler and g-ir-compiler(1)
as it was documented to "can only be used if --code is also specified",
so no reason to keep it around.
Return a non-zero result when opening the output file fails and
don't use g_error() for other failures when writing out the file,
since such errors should not produce a core dump.
We never actually include multiple modules in the compiler,
so just nuke that. Also rather than passing around GIrModule
consistently pass around a GIrTypelibBuild structure which
has various things.
This lets us maintain a stack there which we can walk for
better error messages.
Also, fix up the node lookup in giroffsets.c; previously
it didn't really handle includes correctly. We really need to
switch to always using Foo.Bar (i.e. GIName) names internally...
It can't really work right now because we rely on dumping data at runtime,
which requires the library. If in the future we support static scanning,
we can reinvestigate embedded typelibs.
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.
Add a toplevel GirParser object to hold state that is global across
a compilation. Currently just holds the include path, but will
eventually also keep a cached list of parsed modules.
svn path=/trunk/; revision=901
* gir/Makefile.am: Dep on Makefile
* girepository/ginfo.c: Print out a nicer error
message if we failed to load something.
* girepository/girepository.c: Clean up
default typelib handling; remove global
default_typelib variable. Ensure we handle
NULL repository in more places.
Support dependency resolution.
* tests/Makefile.am: Kill off gobject.gir,
it conflicts with the real one.
* tests/Object.gir: Depend on GObject.
* tools/generate.c: Take --includedir
argument to say which directories to search
for typelibs. Print out dependencies.
svn path=/trunk/; revision=541
* gir/Makefile.am: Use --includedir
* girepository/girparser.c: Recursively parse
includes to pull in aliases and expand them.
We need this to avoid putting unknown names in
the typelibs.
* tools/compiler.c: Add --includedir option.
svn path=/trunk/; revision=512
2008-08-28 Tor Lillqvist <tml@novell.com>
* tools/compiler.c (write_out_typelib): Use binary mode for output
file on Windows.
* girepository/girnode.c: Don't print NULL strings.
* tests/invoke/Makefile.am
* tests/scanner/Makefile.am: Use -no-undefined on Windows to
convince libtool to build shared libraries.
* tests/invoke/invoke.c: Don't needlessly include <dlfcn.h>. Use
g_assert() instead of printing out expected errors.
svn path=/trunk/; revision=509
2008-02-22 Mark Doffman <mark.doffman@codethink.co.uk>
* tools/quote-file.sh
* tools/compiler.c
* tools/generate.c
Move to using the 'C' struct compiler code.
WARNING: This commit does not compile. It is a partial change.
svn path=/trunk/; revision=135
* src/compiler.c, src/generate.c, src/gidlnode.c,
src/gidlparser.c, src/ginfo.c, src/girepository.c,
tests/invoke/invoke.c, test/invoke/testfns.c: Hush compiler
warnings about return values, signedness mismatches, unused
variables, and unhandles enum values in switch statements.
* tests/invoke/Makefile.am: Don't install the invoke test program.
Add -I ../../src to the cflags used for the test functions files.
2005-05-24 Matthias Clasen <mclasen@redhat.com>
* src/compiler.c (main): Use it here to validate
the generated metadata.
* src/gmetadata.[hc]: Add code to validate a
metadata blob.
2005-05-13 Matthias Clasen <mclasen@redhat.com>
* src/compiler.c (format_output): Make the generated
C code compile.
* README: Point to a recent libffi snapshot.
* tests/invoke/*: Some invoke tests.
* src/Makefile: Add ginvoke.c and the necessary
libffi information.
* src/girepository.h (g_function_info_invoke): Add
a GError argument.
* src/ginvoke.c (g_function_info_invoke): Initial
implementation of invoke functionality based on libffi.
2005-05-11 Matthias Clasen <mclasen@redhat.com>
* src/compiler.c (main): Add a --verbose cmdline option
and only log messages if it is specified.
* src/gidlnode.h:
* src/gidlnode.c (init_stats, dump_stats): Collect some
statistics on string and type sharing.
* src/gidlmodule.c (g_idl_module_build_metadata): Use
g_message() instead of fprintf().
* src/gidlnode.c (g_idl_node_free): Make this more robust.
(g_idl_node_get_size): Implement for structs.
(g_idl_node_get_full_size): Handle parent being NULL.
(serialize_type): Handle lookup failures more gracefully.
2005-05-10 Matthias Clasen <mclasen@redhat.com>
* src/gidlnode.c (g_idl_node_get_full_size): Correct the
size calculation for 2-parameter types and for objects.
* src/compiler.c: Add a cmdline option for debug output
and install a log handler to implement it.
* src/gidlnode.c: Add some debug spew.
This also fixes the build for AArch64 since cmph_uint32 is not big
enough to hold a pointer there. I found this while building for CHERI
since the compiler errors there when casting from a non-inptr_t integer.
This also fixes warnings when building for AArch64 with clang.
Not sure what it was doing there — these arguments get written to as
part of the invocation. The in-args should be `const` qualified, but not
the out-args.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
The whole point of a `GICallableInfo` struct is to contain information
about how a function is callable, and that includes information about
whether it’s a method and whether it throws a `GError`. The caller
shouldn’t need to specify those things separately.
So drop those arguments.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It’s more descriptive and less offensive.
This is not an API break as it’s not a public API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It was deprecated since before libgirepository was moved into this
repository. Take the opportunity now to remove it entirely, as it’s a
bit confusing to have it in the public API.
This should not affect the binary typelib format, as it still has its
`BLOB_TYPE_INVALID_0` member, and that will remain in place until the
binary format next breaks compatibility (no plans to do that).
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
And rename it to `gi_repository_get_shared_libraries()`. Previously it
returned a comma-separated string, which wasn’t particularly typesafe or
machine-friendly. Now it returns the same data as an array.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Having it be nullable means the type system forces the caller to check
the result for nullability every time, even though it’s straightforward
for the caller to check the index argument in advance and guarantee a
non-`NULL` result.
Change `gi_repository_get_info()` to never return `NULL` to tidy this
up. This also brings it inline with other `gi_*_get_info()` functions,
which are not nullable.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
A few applications such as gnome-music load the GIRepository typelib
and use it to adjust their search paths.
GLib 2.79.x now provides libgirepository-2.0.so.0 (GIRepository-3.0),
but each OS distribution is likely to have a transitional period during
which GLib's libgirepository-2.0.so.0 has become available, but bindings
like PyGI and gjs are still linked to gobject-introspection's
libgirepository-1.0.so.1 (GIRepository-2.0).
During this transitional period, interpreted languages that load the
GIRepository namespace could get the "wrong" version, which will result
in adjusting a search path that will not actually affect the language
binding's typelib lookup, and could also lead to symbol and type-system
conflicts.
We can avoid this collision by making GLib's GIRepository library refuse
to load versions of the GIRepository typelib that are not 3.0, and
similarly making gobject-introspection's GIRepository library refuse to
load typelib versions that are not 2.0. A relatively neat way to achieve
that is to make each version behave as if the other one doesn't exist.
Signed-off-by: Simon McVittie <smcv@debian.org>
The library shipped by gobject-introspection.git was
`libgirepository-1.0.so`, but for some reason (accident?), it was
accompanied by `GIRepository-2.0.gir`. That’s been the case for the last
6 years.
In moving libgirepository to glib.git, we’ve bumped the version to
`libgirepository-2.0.so`, and have changed the API.
In order to avoid a collision between the new `GIRepository-2.0.gir` and
the old `GIRepository-2.0.gir`, we can either:
* Rename the basename of the library (confusing).
* Re-version the whole thing to 3.0 (would mean it’s completely out of
sync with the rest of glib.git, and would lead to build system
misery).
* Re-version only the GIR file (a bit confusing, but hopefully less
confusing).
So I’ve done the final option: glib.git now ships
`libgirepository-2.0.so` and `GIRepository-3.0.gir`. This avoids
collisions with what’s shipped by gobject-introspection.git, while
hopefully still making some sense.
We considered using version number 2.1 rather than 3.0, but decided
against it because that makes it look like it’s compatible with version
2.0, which it isn’t.
Note that none of these changes touch the
`${prefix}/lib/girepository-1.0` and `${prefix}/share/gir-1.0`
directories. The version numbers in those refer to the versions of the
GIR and typelib file formats, which have not changed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
We used to store the search paths into a GSList but this is not
efficient for various reasons, so replace this with an array so that we
can replace return just a GStrv in the public API.
Generating gir and typelib files has inter-dependencies that may depend
on other elements.
For example, glib requires gobject and gdump generated files require
gmodule, so we've a cyclic dependency because gmodule requires gobject,
that requires glib.
To prevent this, let's just generate the introspection files at once in
a different meson file so that we don't have to deal with this.
As per this we could even revert commit fa37ab6d0 since gio is now
compiled before the gir files.
It’s not particularly necessary, and makes the build-time dependencies
more complex than they need to be, as it means that to generate
GLib-2.0.gir and GObject-2.0.gir, libgio.so (and its generated headers)
already needs to have been built.
See discussion on https://gitlab.gnome.org/GNOME/glib/-/issues/3164
These changes need to be replicated in gobject-introspection.git before
the problem can be solved, though, as that still has its own copy of
`gdump.c` (which it installs and uses).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3164
If more documentation needs to be added, it either needs to be added as
docblock comments next to the relevant symbols, or as additional
Markdown files. Not in a random C file.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Accepting two filenames as a string comma-separated string seems like a
layering violation: this is a public API which could be used in places
other than directly off a set of command line arguments.
Move the command line argument parsing to the command line callback.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Because they return the function name, not a `GIFunctionInfo` for the
function, or anything else.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This is an API break, but libgirepository has not been in a stable
release yet, so that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Indicate that they return an argument index, not the argument itself.
This is an API break, but libgirepository has not been in a stable GLib
release yet, so that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This makes it more conventional for how `GType` code is normally written.
This introduces no functional changes, but it is an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
For the moment, this is enough to roughly verify that the port to
`GTypeInstance` has not massively broken things. It’s not anywhere near
sufficient to qualify as a proper test suite though.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
If they’re all named after the actual library name, rather than a
contraction of it, that’s easier to remember so they can be easily
referenced elsewhere in the build system (such as when adding unit
tests).
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It’s not intended that most people will use this, but it’s going to be
quite useful for adding unit tests — we don’t really want the unit tests
to share global state (a singleton `GIRepository`) between tests.
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
This is an API break, but that’s fine since we haven’t frozen the
libgirepository API yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This method doesn’t return a `GType`, so when the code gets ported to
`GTypeInstance` in an upcoming commit, that will become quite confusing.
Rename it to `gi_base_info_get_info_type()` instead.
This introduces no functional changes, but it is an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
The `type` field will eventually disappear, so use an accessor method to
get it.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These aren’t needed at the moment, since all the `TypeInfo` structs in
libgirepository are all aliases for each other.
An upcoming commit will change that, however, so we need to be a little
bit stricter about type safety in advance.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These methods don’t return a `GType`, so when the code gets ported to
`GTypeInstance` in an upcoming commit, that will become quite confusing.
Rename them all to `get_type_info()` instead.
This introduces no functional changes, but it is an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
