GIR warnings

[worldofpeace]

Describe the bug

Building the latest released granite I see these warnings in the build output

../lib/Services/Application.vala:21.1-21.26: warning: Namespace Services does not have a GIR namespace and version annotation
namespace Granite.Services {
^^^^^^^^^^^^^^^^^^^^^^^^^^
../lib/GtkPatch/AboutDialog.vala:23.1-23.54: warning: Namespace GtkPatch does not have a GIR namespace and version annotation
public class Granite.GtkPatch.AboutDialog : Gtk.Dialog {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
../lib/Drawing/BufferSurface.vala:25.1-25.25: warning: Namespace Drawing does not have a GIR namespace and version annotation
namespace Granite.Drawing {
^^^^^^^^^^^^^^^^^^^^^^^^^
../lib/Widgets/AboutDialog.vala:22.1-22.25: warning: Namespace Widgets does not have a GIR namespace and version annotation
namespace Granite.Widgets {

Platform Information

NixOS 20.30 (development).

Please check what applies:
-->

• I'm using the latest version from git that I've manually compiled
• I'm using the latest released stable version

[ricotz]

Preferably granite should not contain nested namespaces at all. Those are not supported by the GIR format and vala isnt fully capable to transform those. https://gitlab.gnome.org/GNOME/vala/issues/541

[raggesilver]

I'm currently not able to generate my project's gir file because of this.

Could not find GIR file 'GraniteServices-1.0.gir'; check XDG_DATA_DIRS or use --includedir

This file most likely doesn't exist and is just an issue related to nested namespaces, correct? Anything I can do about it?

[Letterus]

Just to add a note: Would be really great if we could improve GIR quality for Granite. That would make language bindings a lot easier (I'm working on bindings for Objective-C).

Biggest hindrance currently: Generating bindings for libgee. Gee GIR quality is so low, I fail to generate anything that compiles.

As far as search found there are only two dependencies to Gee:

granite/lib/Services/AsyncMutex.vala

Line 16 in 72120f9

private Gee.ArrayQueue<Callback> callbacks;

granite/lib/Services/ContractorProxy.vala

Line 154 in 72120f9

private static Gee.HashMap<string, GenericContract> contracts;

These are private and thus not part of the API. Maybe they could be replaced by some data types from GLib/libgio that have decent GIR quality?

I found:

• https://valadoc.org/glib-2.0/GLib.Queue.html
• https://valadoc.org/glib-2.0/GLib.HashTable.html

[lenemter]

@Letterus libgee's gir quality is good though..? Almost 20k lines long and has both Gee.ArrayQueue and Gee.HashMap. I attached the file from my OS 8 install. Had to rename it to txt because Github doesn't support gir files
Gee-0.8.txt

[Letterus]

@lenemter Thank you for your reply. Would be great if this was correct, but sadly it's not. Use https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/main/misc/validate-gir.py?ref_type=heads for a quick first check.

Gtk 4

misc$ python validate-gir.py -S ../docs/gir-1.2.rnc /usr/share/gir-1.0/Gtk-4.0.gir

-> No output, no issues.

Gee 0.8

misc$ python validate-gir.py -S ../docs/gir-1.2.rnc /usr/share/gir-1.0/Gee-0.8.gir 
Validation errors: /usr/share/gir-1.0/Gee-0.8.gir:9094:0:ERROR:RELAXNGV:RELAXNG_ERR_INVALIDATTR: Invalid attribute nullable for element field
<string>:0:0:ERROR:RELAXNGV:RELAXNG_ERR_INTEREXTRA: Extra element field in interleave
/usr/share/gir-1.0/Gee-0.8.gir:9093:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element record failed to validate content
<string>:0:0:ERROR:RELAXNGV:RELAXNG_ERR_INTEREXTRA: Extra element record in interleave
/usr/share/gir-1.0/Gee-0.8.gir:9:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element namespace failed to validate content
/usr/share/gir-1.0/Gee-0.8.gir:3:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element repository failed to validate content

Granite 7

Looks much better though:

misc$ python validate-gir.py -S ../docs/gir-1.2.rnc /usr/share/gir-1.0/Granite-7.0.gir 

-> No issues found.

Workaround

This lead me to the solution to leave out Gee as dependency during generation (meaning to only refer to the plain C implementation without any further wrappers/bindings) and only generate bindings for Granite-7. This worked quite well. I could compile the wrappers very quickly. I was only missing the type macros for some types, namely missing or spelled differently were:

• GRANITE_TYPE_SERVICES_CONTRACTOR_PROXY (granite_services_contractor_proxy_get_type() works though)
• GRANITE_TYPE_SERVICES_SYSTEM (granite_services_system_get_type() works though)

I think both issues refer to the problem mentioned above and the workaround mentioned by @ricotz @ #366 (comment)