This functionality is used in both PyGObject and GJS, and if not done
correctly can lead to architecture-specific bugs. It seems best to add
API in gobject-introspection for the correct way to do it.
See also: GNOME/gjs#309
ba744068 ("Make meson.override_find_program working on more complex use
cases") made the build no longer reproducible by encoding a build system
path into the output. This shouldn't be necessary anyway, since it
should be possible to add new paths to search for gir files by setting
the XDG_DATA_DIR environment variable.
Closes#318
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
There are notably 4 classes of GTypes where a girepository lookup
might fail:
- GTypes from private interfaces in public objects (eg. MetaCullable in
mutter)
- GTypes for private base objects with public interfaces (eg. GLocalFile
in GLib)
- GTypes registered from the language, and presumably not coming from the
GIR
- GTypes of objects/interfaces that we didn't load a typelib for
It is moot to look for those over and over again, and a full lookup can
be taxing if looking up for a method/property on objects with those
characteristics.
It seems we can cache the misses too, so next lookups are just as quick
as an introspected GType. The cache is invalidated after loading new
typelibs, in case some of the previously missed GTypes is now properly
introspected.
Add some missing `meson.override_find_program`
And make sure that the `.gir` we build are found when used uninstalled
as a concequence of `meson.override_find_program`.
The current offset only considers the fields themselves, but not
the optional embedded type that may follow each field.
Use the existing helper function instead of computing the offset
to fix the issue.
In our case it was never needed because it defaults to true if install_dir is set,
which it always is for all calls.
This avoids a warning when running with newer meson where it complains that install
is only available with 0.50+.
Fixes#298
In g_irepository_get_object_gtype_interfaces(), returning the address of
the first GIBaseInfo* does not work reliably, because the GIBaseInfos
are not necessarily stored contiguously. So the second and subsequent
ones might be garbage.
Instead, return the address of the array of GIBaseInfo pointers.
Add a test that verifies the functionality, as well.
This is unfortunately an API and ABI break.
By doing so, we essentially cover the various compiler flags that we
want to use for non-Visual Studio builds to check for warnings that
might cause real concern.
This also skips the checks for the various GCC-isque CFlag checks that
are scattered in the various build files on Visual Studio builds, since
they are essentially meaningless on Visual Studio builds.
If g_mapped_file_new fails, then `version` will be freed, but it was
already added to the hash table. This means there could be a
use-after-free while doing a lookup on the hash table the next time.
If a transitive dependency appears twice, the original pointer will be
removed from the hash table. Since these names were created by
g_strsplit, they need to be freed, or they will leak.
Bindings in some cases need to look up information from a GType
dynamically. Support that better by supplying a cache for this
information.
(Rebased and versioning / gtk-doc stuff added by Philip Chimento.)
Closes#38.
See gjs#55.
This enables various compiler warnings project wide and disables the triggered
ones for each library/executable. This should give us roughly the same behaviour
as with autotools.
Tested with gcc8 and clang7.
This adds the following macros and functions: GI_MAJOR_VERSION, GI_MICRO_VERSION,
GI_MINOR_VERSION, GI_CHECK_VERSION, gi_get_major_version,gi_get_micro_version,
gi_get_minor_version.
Since we share a prefix with glib we have to namespace these by using the gi_
prefix. g_gi would also work but we already export symbols with gi_ like
gi_cclosure_marshal_generic(), gi_type_tag_get_ffi_type() and
gi_type_info_extract_ffi_return_value(), so let's not add another naming scheme.
GITypeInfo is a GIBaseInfo so calling g_base_info_get_name() on it should do something
sensible.
g_base_info_get_name() has always been documented to return NULL in case no name
is available so return that instead.
The gtk-doc docs were including some bits of overal g-i docs but mostly unfinished
and outdated.
We now have the general docs in sphinx so remove the duplication and make the gtk-docs
just about the libgirepository API and nothing more.
This also renames some titles and fixes some missing links in the struct hierarchy
while at it.
Move things around and rename things until gtk-doc is happy.
This also moves the "Since" annotations to the next stable releases and
adds version added info for g_callable_info_get_instance_ownership_transfer()
and g_struct_info_find_field().
Some documentation tool (as hotdoc[0]) need to have information about
symbol declaration and documentation positions in the source files
to be able to do smart indexing (automatically build the documenation
index).
[0] https://hotdoc.github.io/Fixes#175
In case the surrounding code handles missing cases break, otherwise add
a g_assert_not_reached().
The generated parser code triggers this as well, so disable it there only.
Where it's easy add dummy args to match the cast; where the target is a subset just
prevent the warning with a cast to void*.
Provide a real copy function for the boxed type code in regress_foo.
This code is never executed afaics, but why not.
On Windows (Visual Studio at least), unsigned longs are always 4 bytes,
on both 32-bit and x64 Windows, so we cannot use unsigned longs to deal
with pointers on 64-bit builds, as pointers are 8 bytes on 64-bit
Windows, which may well render the pointer (which we acquired from
libffi) invalid.
This will fix crashes in PyGObject which are manifested when launching
the cairo-demo example sript (intermittent) and when clicking on
"Interactive Dialog" button in the Dialog demo in the PyGObject GTK+
Code demos before entering anything in Entry 1 and Entry 2, when running
on x64 Visual Studio builds of the GTK+/PyGObject stack.
Also use size_t instead of unsigned long in gthash.c when we check that
memory & 0x3 is 0, to silence compiler warnings from enabling /Wp64,
which is used to detect portability problems on Visual Studio when
doing x86->x64 code builds.
https://bugzilla.gnome.org/show_bug.cgi?id=702788
When building with Meson, we cannot set environment variables while
running custom targets and our builddir layout is different from
Autotools anyway.
Now g-ir-scanner and friends can autodetect when they're being run
uninstalled by Meson and will find _giscanner.so and the giscanner
python files in the build directory. This is very similar to what
gdbus-codegen uses in glib/gio.
Same for girepository/gdump.c.
glib_dep is what is actually needed to #include <glib.h>, not
gobject_dep. It works incidentally with system gobject/glib but not
when built via subprojects.
