| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generated C file
When g-ir-scanner is used by another project, than that project might
have the GLIB_VERSION_* macros defined. This is useful to ensure that
only intended glib API is used.
The project might then also pass the CFLAGS to g-ir-scanner, without
filtering those defines out. This can lead to compiler warnings.
For example, NetworkManager sets the version macros to GLIB_VERSION_2_40
and thus gets these warnings
/NetworkManager/tmp-introspect66917zc4/NM-1.0.c: In function ‘dump_object_type’:
/NetworkManager/tmp-introspect66917zc4/NM-1.0.c:252:13: warning: Not available before 2.70
252 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/NetworkManager/tmp-introspect66917zc4/NM-1.0.c: In function ‘dump_fundamental_type’:
/NetworkManager/tmp-introspect66917zc4/NM-1.0.c:370:13: warning: Not available before 2.70
370 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
But these warnings are not correct. The installed g-ir-scanner knows for which
glib version to generate code. Undefine the macros to avoid the warning.
|
|
|
|
|
|
| |
https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
Based on https://github.com/katef/kgt/blob/c9d8ad246855c6b65e42371be7898f4073c28d18/examples/c99-grammar.iso-ebnf#L247-L252
|
|
|
|
|
|
| |
Reset against GLib 2.72.4; some symbols introduced in GLib 2.74 have
managed to sneak in. Luckily, there has been no release off of this
branch, yet.
|
|
|
|
|
| |
We should not try to build a stable gobject-introspection branch against
the latest bleeding edge GLib.
|
|
|
|
|
|
|
| |
The `check` argument to `run_command()` is now mandatory.
(cherry picked from commit 3b5db10205023bfa43a9675a6ade826653a1c41c)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
|
| |
|
|
|
|
| |
This is based on 0c6a1af9d616e110b4610d5a6a992d02ed1a5c21
|
|
|
|
|
| |
In glib-print.c example, make the error message refer to the same function
(GLib.assertion_message) as the code.
|
|
|
|
|
|
|
|
|
| |
Projects like pango depending on fontconfig-2.0.gir or
any other gir provided by gobject-introspection in its
sources directory need to have these gir's available
in the build directory, where the rest of generated
girs are created so they are found when using
gobject-introspection dependency.
|
|
|
|
|
|
| |
Fix sandbox violation using subproject variables
added in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2465
Use global source and build root directories
|
|
|
|
|
|
|
|
|
| |
We attempted to return a value in void-return-type functions in both
gicallableinfo.c and gitypeinfo.c, so avoid that since that will trigger a
C4098 warning on Visual Studio, which is considered an error if we are building
against an installed version of GLib 2.68.x or later.
This will fix builds against GLib-2.68.x and later on Visual Studio.
|
|
|
|
|
|
| |
This fixes support for macros like `g_message()` in GLib.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
|
|
|
|
|
| |
This fixes support for macros like `G_BREAKPOINT()` or `G_DEBUG_HERE()`
in GLib.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| |
|
| |
|
|
|
|
| |
GLib 2.72.0 is now out.
|
|
|
|
|
|
|
|
|
| |
It seems that optparse might just ignore storing options without a
default. In this case, the `--compiler` option should be initialised to
`None`, but instead it just gets ignored.
Without the `hasattr()` check, updating the introspection data for GLib
fails with a Python backtrace.
|
|
|
|
| |
This is based on f61187428eaff51b5aae121df1615e02117ef44f.
|
|
|
|
|
| |
We don't use Autotools, and we don't generate files inside the source
directory any more.
|
|
|
|
|
| |
The main development branch of GObject Introspection is now called
"main", following the change in GLib and GTK.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds gi_type_tag_argument_from_hash_pointer() and
gi_type_tag_hash_pointer_from_argument(). They do the same thing as
the corresponding g_type_info_... functions, which are used to pack and
unpack the correct field of a GIArgument into/from a data pointer in
GHashTable or GList, regardless of machine architecture or endianness.
These functions take a GITypeTag obtained from
g_type_info_get_storage_type(), instead of a GITypeInfo pointer. (The
storage type is the only piece of data that is actually used from the
GITypeInfo structure.)
It's intended for bindings using an argument cache, such as GJS and
PyGObject, so that they don't have to store a whole 64-bit GITypeInfo
pointer in their cache in many common cases, and can just store the 5-bit
type tag instead.
The original g_type_info_... functions are reimplemented in
terms of the new g_type_tag... functions.
|
| |
|
| |
|
|
|
|
|
| |
We need it for close(), especially when unistd.h is not available, such as in
the case of Visual Studio-style builds.
|
|
|
|
|
|
|
|
| |
We can just update the for loop condition to be >0 for all builds, which
is actually equivilant to >=1 as we are essentially comparing an
unsigned 32-bit int, so that we don't need to worry about fixing the
VS2012 bug invasively, as Visual Studio 2012 x64 is more sensitive about
sizes of variables (e.g. pointer sizes in this case)
|
|
|
|
|
|
|
|
|
|
|
| |
The __ia64 and __x86_64__ macros are defined for GCC but not Visual
Studio, but actually this code path should also be taken for Visual
Studio when doing a 64-bit build (x86_64/x64 and aarch64/arm64, _WIN64
will be defined for these cases), since Windows is an LLP64 platform.
This will avoid C4311/C4312 warnings on Visual Studio builds, which are
often warnings of concern as we are dealing with pointers with differing
sizes on 32-bit and 64-bit Windows builds.
|
|
|
|
|
|
|
|
|
| |
Later GLib versions assume that warning C4715 is an error as we want ot
be sure that functions that return a value do indeed return one by all
means.
Avoid this warning by adding a 'return 0' in brz_search_packed(), it
might be pointless but does indeed avoid the warning.
|
|
|
|
|
| |
It's pointless, as docbook's style sheets do not work any
more, but gtk-doc still warns about them.
|
|
|
|
| |
It must match the argument in the definition and the documentation.
|
| |
|
|
|
|
| |
Now that we have it.
|
|
|
|
|
| |
And deprecate G_TYPE_TAG_IS_BASIC. Let's avoid hijacking
the G namespace any further.
|
| |
|
| |
|
|
|
|
|
| |
We are still using gtk-doc, but gtk-doc uses Markdown these days, not
DocBook.
|
|
|
|
| |
It's `/*< ... >*/`, not `/* <...> */`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new API does the same thing as gi_type_info_extract_ffi_return_value,
but takes a GITypeTag instead of GITypeInfo pointer, and additionally a
GIInfoType if the GITypeTag is GI_TYPE_TAG_INTERFACE. (These pieces of
data are the only things used from the GITypeInfo structure.)
It's intended for bindings using an argument cache, such as GJS and
PyGObject, so that they don't have to store a whole 64-bit GITypeInfo
pointer in their cache in many common cases, and can just store the 5-bit
type tag instead, or the 5-bit interface type in case of
GI_TYPE_TAG_INTERFACE.
The original gi_type_info_extract_ffi_return_value() is reimplemented in
terms of the new gi_type_tag_extract_ffi_return_value().
|
|
|
|
|
| |
It was driving me crazy that g_type_info_get_array_length() claimed to
return an array length.
|
|
|
|
|
|
|
| |
The documentation comment for SimpleTypeBlob seemed to imply that a basic
type was embedded if the reserved fields were nonzero. After examining the
code, I believe that was actually due to some words missing, and the
comment should say that the type is embedded if the fields are zero.
|
|
|
|
|
| |
Like GI_TYPE_TAG_IS_NUMERIC, this is a convenience for bindings that want
to perform a similar action for all container types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a convenience for bindings that want to perform a similar action
for all numeric types. It allows more expressive code in some cases:
if (GI_TYPE_TAG_IS_NUMERIC(tag)) {
do_one_thing();
return;
}
switch (tag) {
case GI_TYPE_TAG_ARRAY:
do_other_thing();
return;
/* ... */
default:
g_assert_not_reached();
}
instead of listing out all of the numeric types in the switch statement.
|
|
|
|
|
|
|
|
|
| |
This reverts commit 8e85d1ca937c166f07675d02fc84abb27d06ae11.
Marking colliding properties as not introspectable breaks
a bunch of existing API when compiling the GIR into the
typelib, so we'll have to find another solution during the
grace period.
|
|
|
|
| |
This is based on f9c08308ea0c25977b4e0153e868cb0a8703b75e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently use the `CC` environment variable to find the C compiler to
use internally in g-ir-scanner. Build systems might wish to store the
compiler detected during the build configuration, and then pass that
compiler to g-ir-scanner at the time of build, avoiding to put things
into the environment.
One possible solution is to have a command line argument that lets us
specify the C compiler, with the same semantics as the `CC` environment
variable.
|
|
|
|
|
|
|
|
|
| |
Follow the same semantics as Vala:
1. emitters should have the same return value as the signal
2. emitters should have the same parameters as the signal they
emit (minus the instance parameter, which is implied in
signals)
|
|
|
|
|
|
| |
Signals that have an emitter function should have an annotation to allow
consumers of the introspection XML to effectively pair signals to their
corresponding emitter functions that share the same prototype.
|
|
|
|
| |
We need to use log_node(), not a plain log().
|