Adding some initial test for the compiler behavior and its expected
output.
Also, when using sanitizers we want to be able to test the compiler memory
management.
The deprecated construct '@0@'.format(h) (where h is a file object)
expanded to the filename relative to the project root, which in this
particular case happens to be what we wanted:
`--c-include=gio/gunixmounts.h` resulted in a recommendation to
`#include <gio/gunixmounts.h>` and so on. Replacing it with
h.full_path() resulted in GIR XML and documentation that recommended
constructs like `#include </home/me/src/glib/gio/gunixmounts.h>`,
which is not what was intended (and caused new differences between
different architectures' Gio-2.0.gir on multiarch systems, which is
how I discovered this).
Hard-coding `gio/` and appending the basename of the header seems like
the simplest non-deprecated spelling that will do what we wanted.
Fixes: 51e3e7d9 "build: Bump Meson dependency to 1.4.0"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3564
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously `gi_object_info_find_signal()` used `gi_object_info_get_signal()`
to retrieve the *i*th signal and compare its name to the desired name.
However, `gi_object_info_get_signal()` returns an allocated object.
If the names were not matching, the allocated object was simply dropped,
and this resulted in a lot of unnecessary allocations compared to the
desired number of allocations, which is one.
To avoid much of the overhead pertaining to the creation of these allocated
`GISignalInfo` objects, introduce a new function that inspects the signal
blobs directly and returns an allocated `GISignalInfo` object just for the
matching signal. The function is largely a copy-and-paste of `gi_base_info_find_vfunc()`,
which does the same thing, only for virtual functions.
See https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/504
This follows the usage in the glib codebase and recommendations at
main/docs/toolchain-requirements.md
It also fixes a build warning with ancient gcc 4.8:
../girepository/gitypelib-internal.h:202:1: warning:
no previous prototype for ‘_blob_is_registered_type’ [-Wmissing-prototypes]
Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the
glib Meson policy says we can update. Update the minimum only as far as
1.4.0 because we don't yet have a need for 1.5.0.
This allows us to:
- Use file.full_path() to avoid deprecation warnings on str.format(file).
- Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC.
Update all the CI builds to use the latest 1.4.x patch release, 1.4.2.
The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be
broken for now.
Similarly, the macOS build will not work unless `-Dc_std=gnu99` is
specified at configure time, due to
https://github.com/mesonbuild/meson/issues/13639.
It’s unclear why there was a hole in this. Let’s keep things less
confusing by eliminating it.
Fixes commit 453dd4be9e906078a7fb7466819ce1876a629a45.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It's gio-windows-2.0.pc, not gio-win32-2.0.pc.
Otherwise, we get warnings/errors where the package cannot be located
but since we are linking to the same GIO library file, this did not
manifest itself.
When building a typelib, the values of constants need to be converted
from a string format (from the GIR) to a binary format. This is
currently done, for all numeric types, using `g_ascii_strto*()`
functions, but with minimal validation. String values which are not
representable as binary numbers are either silently truncated or
clamped.
`-Wfloat-conversion` has flagged that this happens for floats – a
double-precision return from `g_ascii_strtod()` is implicitly cast down
to a float.
While we should ideally have some better error handling so that
conversion to a typelib fails if a constant is not representable in the
typelib, this is a problem for *all* numeric types and not just `float`,
so add an explicit cast to ignore the error for now.
In practice there probably isn’t a problem for any numeric types here,
as there should be validation of the string value when the GIR is
generated anyway.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
libgirepository is not needed by most of the modules, but it is needed
by the `g-ir-scanner` generated dumper program. If we don’t explicitly
include the local version of it here, Meson will implicitly link against
it anyway, and that might pull in a different version, or try to link
against a half-built local version as the build ordering dependency tree
won’t reflect this relationship.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3401
As a special case, keep the historical behaviour of treating gchar
as being signed, both on platforms where it is genuinely signed (for
example x86 Linux) and where it is unsigned (for example ARM, s390x
and PowerPC Linux). Changing gchar to use INTEGER_ALIAS would have a
regression risk, so if we want to do that, it should be as a separate
change.
No functional change intended.
Signed-off-by: Simon McVittie <smcv@debian.org>
It’s currently completely untested. Let’s add a few basic tests so that
adding more tests in future is easier.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In macOS compilation fails with the following error:
```
In file included from ../girepository/tests/autoptr.c:23:
../girepository/girffi.h:30:10: fatal error: 'ffi.h' file not found
```
Relocation is a common scenario in macOS applications and frameworks.
This commit provides a mechanism to support relocations by inferring
the typelib dir from the path of the loaded image libgirepository-1.0.dylib.
For historical reasons, some doc blocks are included in an ancillary
file. Add it to the list of sources parsed by g-ir-scanner, to increase
the coverage of various macros.
Fixes: #3372
Since we are now building introspection files for GLib while building
GLib, so we want to make sure that we indeed load the freshly-built
DLLs when running g-ir-scanner, so we add the various needed subdirs
(and if needed, subprojects), to set the GI_EXTRA_BASE_DLL_DIRS
envvar so that g-ir-scanner will look for the newly-built GLib DLLs.
Ideally, upstream g-ir-scanner will need to be updated accordingly to do
something similar to what we are doing here, but this is needed until
the time that we require a g-ir-scanner that contains the update.
This will also fix the g-ir-scanner erroring out when there is no
pre-existing GLib on the system, as the needed DLLs are now found.
Related issue: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/499
Related MR in G-I:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/458
It's just better than a list of strings for various reasons, but mostly
here it allows also to avoid copying the lists but making the
ownership clearer through references
In this way the module can survive without that the parser is fully
alive.
At the moment a module has not a ref-count system, but this makes things
clearer when we return the module from a parser.
In case the node was pushed to a non-empty node stack, then we were not
tracking it in the entries list, and so nothing was freeing it on
destruction.
As per this, once parsing is done, we can free it or we'd leak.
