summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Search XDG_DATA_HOME/gir-1.0 for GIR XML toowip/smcv/search-pathsSimon McVittie2023-03-143-0/+39
| | | | | | | | For completeness. There probably won't be any, but the XDG base directory specification is most useful if it's consistently followed everywhere, and the specification says to look in XDG_DATA_HOME before XDG_DATA_DIRS. Signed-off-by: Simon McVittie <smcv@debian.org>
* girepository: Search the same paths as the Python codeSimon McVittie2023-03-142-0/+15
| | | | | | | | | | | | | | | | | The Python code historically always searched DATADIR/gir-1.0 (always) and /usr/share/gir-1.0 (only on Unix); since the previous commit, they are searched after the GIR_DIR. Do the same here, to make the C and Python search paths match up. With the default gir_dir_prefix, searching both GIR_DIR and DATADIR/gir-1.0 is redundant. However, if gir_dir_prefix is changed to something else, for example -Dgir_dir_prefix=lib64, always searching DATADIR/gir-1.0 provides backwards compatibility with pre-existing GIR that might already be stored in DATADIR/gir-1.0. Resolves: #455 (in conjunction with previous commit) Helps: #323 Signed-off-by: Simon McVittie <smcv@debian.org>
* giscanner: Search the same compile-time GIR_DIR used for the C codeSimon McVittie2023-03-145-10/+16
| | | | | | | | The difference between DATADIR/gir-1.0 and this one is that this one respects the -Dgir_dir_prefix build-time option. Helps: #323, #455 Signed-off-by: Simon McVittie <smcv@debian.org>
* build: Leave gir_dir_prefix unexpandedSimon McVittie2023-03-141-4/+3
| | | | | | | | | This will let us append it to relative paths inside giscanner to get a relocatable path relative to the tools, which seems to have always been the intention. Helps: #323, #455 Signed-off-by: Simon McVittie <smcv@debian.org>
* Add GI_GIR_PATH environment variableSimon McVittie2023-03-145-9/+33
| | | | | | | | | | | | | | | This is searched after any command-line includes paths, but before the XDG_DATA_DIRS or any built-in paths. For example, if libraries are installed in /opt/gnome and GObject-Introspection was configured with -Dgir_dir_prefix=lib64, you could set either GI_GIR_PATH=/opt/gnome/lib64/gir-1.0 or XDG_DATA_DIRS=/opt/gnome/lib64:/opt/gnome/share:${XDG_DATA_DIRS}. Use this to communicate the ../gir directory to giscanner instead of modifying Python's builtins. Helps: #323, #455 Signed-off-by: Simon McVittie <smcv@debian.org>
* Python tools: Don't prepend /usr/share to the search path for GIR XMLSimon McVittie2023-03-141-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This code was presumably intended to add a relocatable path ${bindir}/../${gir_dir_prefix}/gir-1.0 to the search path, where ${bindir} is computed at runtime and ${gir_dir_prefix} is hard-coded at configure time. However, this didn't work as intended for two reasons: * the gir-1.0 suffix was missing, so in practice we would look for GIR XML in a location like /usr/share/Gio-2.0.gir or /usr/lib64/Gio-2.0.gir, not find it, and proceed to the next search path entry; * the @gir_dir_prefix@ substituted from the build system is currently an absolute path, so os.path.join would discard ${bindir}/.. and use the compile-time @gir_dir_prefix@ as-is If this had worked as intended, its precedence would also have been inconsistent with the C code: the Python code searches GIRDIR before the XDG_DATA_DIRS, but the C code searches its direct equivalent, GIR_DIR, after the XDG_DATA_DIRS. Since this doesn't seem to be doing anything useful, discard it. This leaves builtins.GIRDIR set to either empty (normally) or just the ${srcdir}/gir/ (when running uninstalled). Helps: #323, #455 Signed-off-by: Simon McVittie <smcv@debian.org>
* girparser: Emit debug messages to show the GIR XML search pathSimon McVittie2023-03-141-0/+6
| | | | | | | This makes it a bit easier to see what is going on than using strace. Helps: #323, #455 Signed-off-by: Simon McVittie <smcv@debian.org>
* Release gobject-introspection 1.76.01.76.0Emmanuele Bassi2023-03-132-2/+8
|
* Update GIR data for GLibEmmanuele Bassi2023-03-133-25/+88
| | | | Sync up to GLib 2.76.0
* CI: Show the exact commit we are building for each subprojectSimon McVittie2023-03-133-0/+14
| | | | Signed-off-by: Simon McVittie <smcv@debian.org>
* docs: Fix `deprecated` typeNahu2023-03-041-1/+1
|
* Post-release version bump to 1.75.7Emmanuele Bassi2023-02-141-1/+1
|
* Release gobject-introspection 1.75.61.75.6Emmanuele Bassi2023-02-132-1/+8
|
* Reword closure annotation documentationbadcel2023-02-131-8/+6
|
* docs: Be more specific on error out casesCorentin Noël2023-02-131-1/+3
| | | | | Add a disambiguation of what to return and do with the out values in case an error is thrown.
* Update GLib introspection dataEmmanuele Bassi2023-02-132-76/+469
| | | | Use GLib 2.75.3.
* build: Disable GLib's tests when building it as a subprojectSimon McVittie2023-02-131-1/+2
| | | | | | | | We don't need to compile or run GLib's test suite as part of building GObject-Introspection: any failures there are not GObject-Introspection issues. This should make CI somewhat quicker. Signed-off-by: Simon McVittie <smcv@debian.org>
* ci: Allow MSYS2 jobs to failEmmanuele Bassi2023-02-131-0/+2
| | | | | | There's something broken in the MSYS2 jobs, and nobody is actually looking at them. We can't let this block forever, so we temporarily allow them to fail until somebody can diagnose the issue.
* Update GLib introspection datawip/smcv/testbuildRico Tzschichholz2023-01-303-106/+138
| | | | Use GLib commit f499e37979c09409d553a49562c6a0a9a65267af
* Update GLib introspection dataSebastian Dröge2023-01-302-25/+83
| | | | This is based on GLib ce876ab28bb81ac0b1c313223284de722d8208a1.
* Fix gir build when using subprojects' dependenciesAndoni Morales Alastruey2023-01-273-0/+16
| | | | | | | | https://github.com/mesonbuild/meson/pull/10275 introduced support in meson to use uninstalled .pc files in the meson-uninstalled directory to resolve dependencies built with subprojects. Replicate the same solution while all the custom_target are migrated to gnome.generate_dir
* Post-release version bump to 1.75.5Emmanuele Bassi2023-01-091-1/+1
|
* Release GObject-introspection 1.75.41.75.4Emmanuele Bassi2023-01-092-2/+7
|
* build: Remove subproject fallbackEmmanuele Bassi2023-01-091-14/+8
| | | | We don't need it any more.
* build: Override required GLib versionEmmanuele Bassi2023-01-091-2/+3
| | | | We passed GLib's own version, so we need to reset the requirement.
* Post-release version bump to 1.75.3Emmanuele Bassi2023-01-091-1/+1
|
* Release gobject-introspection 1.75.21.75.2Emmanuele Bassi2023-01-092-1/+11
|
* Update version to 1.75.1Emmanuele Bassi2023-01-081-1/+1
|
* tests: Use the appropriate assertion methodEmmanuele Bassi2023-01-081-53/+55
| | | | | | - assertEqual(value, None) → assertIsNone(value) - assertTrue(value is not None) → assertIsNotNone(value) - assertTrue(isinstance(value, Type)) → assertIsInstance(value, Type)
* Use the pointer attribute in libgirepositoryEmmanuele Bassi2023-01-084-20/+75
| | | | | | The "disguised" attribute is there only for backward compatibility; we use the "pointer" attribute as the authoritative way to indicate a typedef to a struct pointer.
* Split disguised attribute into twoEmmanuele Bassi2023-01-0811-20/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The disguised attribute started off as a way to indicate a typedef to a structure pointer, e.g. typedef struct Foo* FooPtr; Over the years, though, it started to include opaque structure types, e.g. typedef struct _FooObject FooObject; typedef struct _FooObjectClass FooObjectClass; This has led to issues in language bindings, code generators, and documentation generators, which now have issues when dealing with both pointer aliases and opaque types. An initial attempt at fixing this mess in commit f606183a ended up breaking Vala, and had to be reverted. To avoid breaking existing users we can follow a similar approach to the allow-none/nullable/optional solution: 1. introduce a new pair of attributes: "pointer" and "opaque" 2. deprecate the "disguised" attribute The "pointer" attribute covers the case of pointer types. The "opaque" attribute covers the case of opaque structured types. See also: https://gitlab.gnome.org/GNOME/vala/-/issues/735 Fixes: #101
* Revert "scanner: don't accept invalid symbols in binary expressions"Emmanuele Bassi2023-01-087-41/+84
| | | | This reverts commit b37f24b7e27a77c398f41cc331608aff806f0d42.
* GIMarshallingTests: Free and copy GStrv instancesMarco Trevisan (Treviño)2023-01-081-0/+2
| | | | | A GIMarshallingTestsBoxedStruct includes a GStrv, but we don't copy or free it properly.
* Document the newly added attributesEmmanuele Bassi2023-01-082-0/+16
| | | | | Add the (copy-func) and (free-func) annotations to the documentation, and the copy-function and free-function attributes to the GIR schema.
* test: Add regression test for the new tagsEmmanuele Bassi2023-01-086-229/+260
|
* Add copy and free function annotations for POD typesEmmanuele Bassi2023-01-0814-15/+287
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Plain Old Data (POD) types with or without a representation in the GType type system can still have a copy and/or a free function. We should allow annotating these types with their corresponding functions for copying their data into a new instance, and freeing their data. From a language bindings perspective, POD types should have a boxed GType wrapper around them, so they can use the generic GBoxed API to copy and free instances; from a documentation perspective, though, it'd be good to have a way to match a structured type, like a struct or a union, with its copy and free functions. In order to do that, we add two new header block annotations: - (copy-func function_name) - (free-func function_name) These annotations work exactly like ref-func and unref-func for typed instances: /** * GdkRGBA: (copy-func gdk_rgba_copy) * (free-func gdk_rgba_free) * @red: ... * @green: ... * @blue: ... * @alpha: ... * * ... */ The function is stored in the GIR data as two new attributes for the `<record>` and `<union>` elements: <record name="RGBA" c:type="GdkRGBA" copy-function="gdk_rgba_copy" free-function="gdk_rgba_free" glib:type-name="GdkRGBA" glib:get-type="gdk_rgba_get_type" c:symbol-prefix="gdk_rgba"> The annotations are not mandatory. See: #14
* Open g-i 1.75 developmentEmmanuele Bassi2023-01-081-0/+14
|
* Add `default-value` annotationEmmanuele Bassi2023-01-085-7/+37
| | | | | | | An escape hatch to specify a freeform string for the default value of a property. Fixes: #4
* Skip default-value for non-transformable propertiesEmmanuele Bassi2023-01-083-45/+34
| | | | | | | If we can't transform a property default value to string, we are not going to add a default-value attribute to the GIR. This is necessary because non-transformable values may not always be pointers, so we cannot default to "NULL".
* Add an optional attribute for the property default valueEmmanuele Bassi2023-01-086-25/+75
| | | | | | | | | The default-value attribute for a property element is fundamentally meant for documentation generators. We only care about the GIR data, as the conversion from the default value to a string is lossy by definition, and may very well not roundtrip.
* Dump the default value of object propertiesEmmanuele Bassi2023-01-081-2/+45
| | | | | | We use g_param_spec_get_default_value() to get the default GValue of a GParamSpec, and then we serialize it into a string according to the value's own contents and type.
* Remove function "FT_Library_Version"badcel2023-01-081-7/+0
| | | | The function is not usable for language bindings as no shared library name is defined in the gir file and the parameters do not match upstream function signature.
* Update GLib introspection dataEmmanuele Bassi2023-01-083-50/+509
| | | | Use GLib commit ec3b1bfc45216850c1a861055ad2fd9d9906813a (tag: 2.75.2)
* scanner: don't accept invalid symbols in binary expressionsLubomir Rintel2023-01-087-84/+41
| | | | | | | | | | | | | | | | | | | | | The rules for binary expressions were entirely oblivious to the type of the operand symbols and assumed they're integer constants. This is very unfortunate, since it caused all sort of nonsense to end up getting accepted. One such example is the following define from NetworkManager's libnm: #define NM_SETTING_PARAM_SECRET (1 << (2 + G_PARAM_USER_SHIFT)) As G_PARAM_USER_SHIFT is unknown, it was parsed as an invalid symbol. The addition didn't care, treated it as: #define NM_SETTING_PARAM_SECRET (1 << (2 + 0)) Let's just ensure we get CSYMBOL_TYPE_CONST only when both operands actually have const_int_set. Otherwise just create CSYMBOL_TYPE_INVALID. That will cause the symbol to be dropped on the floor eventually, but that's probably much better than a having an invalid value.
* tests/scanner: add some tests for #definesLubomir Rintel2023-01-088-239/+337
| | | | | | | | Add one expanding to an expression we can't get a constant value from and another one for which we can. Note that the bad on one currently does evaluate, and it does so to a bad value. A separate commit with a diff to test suite will address that.
* Track the main branch of GLib as a subprojectEmmanuele Bassi2023-01-081-1/+1
| | | | GObject-introspection is meant to match GLib.
* Bump the project version to 1.75.0Emmanuele Bassi2023-01-081-1/+1
| | | | New cycle, new version number.
* build: Add missing header and symbolsEmmanuele Bassi2023-01-081-0/+3
| | | | | | | | | | | Now that GLib has separate version annotation macros, we need to define GOBJECT_COMPILATION and parse gobject-visibility.h when generating the introspection data for GLib. This MR also requires: - GNOME/glib!3184 - GNOME/glib!3185
* build: Add missing GMODULE_COMPILATION symbolEmmanuele Bassi2023-01-081-0/+1
| | | | | We need to define GMODULE_COMPILATION when building the introspection data for GModule.
* build: Drop wrap files for GLib dependenciesEmmanuele Bassi2023-01-085-28/+12
| | | | We don't need wrap files for things we get from GLib or from the system.
View Lorry Controller Status