GNOME Bugzilla – Bug 652754
No GIR metadata to force a struct to become a class
Last modified: 2011-08-13 08:30:38 UTC
I'm trying to generate libgda-5.0 bindings for Vala from GIR file but I have the following error message: Gda-5.0.gir:15894.7-15894.6: error: Recursive value types are not allowed </field> At this I have the following GdaSqlAnyPart declaration as: struct _GdaSqlAnyPart { GdaSqlAnyPartType type; GdaSqlAnyPart *parent; }; And GIR as: <record name="SqlAnyPart" c:type="GdaSqlAnyPart"> <doc xml:whitespace="preserve">Base structure of which all structures (except #GdaSqlStatement) "inherit". It identifies, for each structure, its type and its parent in the structure hierarchy.</doc> <field name="type" writable="1"> <type name="SqlAnyPartType" c:type="GdaSqlAnyPartType"/> </field> <field name="parent" writable="1"> <type name="SqlAnyPart" c:type="GdaSqlAnyPart*"/> </field> <method name="check_structure" c:identifier="gda_sql_any_part_check_structure" throws="1"> <doc xml:whitespace="preserve">Checks for any error in @node's structure to make sure it is valid. This is the same as gda_sql_statement_check_structure() but for individual #GdaSqlAnyPart parts. This function is mainly for database provider's implementations</doc> <return-value transfer-ownership="none"> <doc xml:whitespace="preserve">TRUE if no error occurred</doc> <type name="gboolean" c:type="gboolean"/> </return-value> </method> <method name="foreach" c:identifier="gda_sql_any_part_foreach" throws="1"> <doc xml:whitespace="preserve">Calls a function for each element of a #GdaSqlAnyPart node otherwise.</doc> <return-value transfer-ownership="none"> <doc xml:whitespace="preserve">TRUE if @func has been called for any sub node of @node and always returned TRUE, or FALSE</doc> <type name="gboolean" c:type="gboolean"/> </return-value> <parameters> <parameter name="func" transfer-ownership="none" scope="call" closure="1"> <doc xml:whitespace="preserve">function to call for each sub node</doc> <type name="SqlForeachFunc" c:type="GdaSqlForeachFunc"/> </parameter> <parameter name="data" transfer-ownership="none"> <doc xml:whitespace="preserve">data to pass to @func each time it is called</doc> <type name="gpointer" c:type="gpointer"/> </parameter> </parameters> </method> </record> In libgda-4.0.vapi we have: [Compact] [CCode (cheader_filename = "libgda/libgda.h")] public class SqlAnyPart { public weak Gda.SqlAnyPart parent; public Gda.SqlAnyPartType type; public bool check_structure () throws GLib.Error; public bool @foreach (Gda.SqlForeachFunc func, void* data) throws GLib.Error; } Do I need a metadata information to "tell" vapigen to use <weak Gda.SqlAnyPart> as the type of parent to avoid recursive? In email response, Bruno Luca response: >The problem is that while in libgda-4 it was a compact class, the gir >says it's a <record> which is a struct. >There's no metadata currently to force a struct to become a class: if you >report a bug I can take care of it, should be trivial. But I can add: It realy need to be a compact class o it is a struct (as defined in C), with just a "weak" pointer to other struct with the same type?
Created attachment 190192 [details] [review] girparser: Add class argument to force records become compact classes Yes, it should be a compact class. Does applying this patch to vala and adding a metadata such as: SqlAnyPart class work for you?
I'm using Vala 0.13.1.199-cd8ff and when compiles the following code using: valac test.vala --pkg Gda-5.0 using Gda; namespace Test { class T : Object { public string name { set; get; } public void connect () { Gda.Connection cnn = Gda.Connection.open_from_dsn("test", null, Gda.ConnectionOptions.READ_ONLY); Gda.SqlBuilder b = new Gda.SqlBuilder(); } } class Hello : Object { public static int main (string[] args) { stdout.printf("Hello\n"); T t = new T(); t.name = "Test All"; stdout.printf("object name: %s\n", t.name); return 0; } } } I get the following messages and errors: [THIS MESSAGE ABOUT vala_code_node_get_attribute_string IS SENT ABOUT 200 TIMES] ** (valac:10836): CRITICAL **: vala_code_node_get_attribute_string: assertion `self != NULL' failed ** (valac:10836): CRITICAL **: vala_code_node_get_attribute_string: assertion `self != NULL' failed ** (valac:10836): CRITICAL **: vala_gir_parser_is_container: assertion `sym != NULL' failed ** (valac:10836): CRITICAL **: vala_gir_parser_is_container: assertion `sym != NULL' failed ** (valac:10836): CRITICAL **: vala_gir_parser_add_symbol_to_container: assertion `sym != NULL' failed Gda-5.0.gir:15983.7-15983.22: error: Recursive value types are not allowed <field name="parent" writable="1"> Segmentation fault (core dumped) Then this not working for this Vala version.
Now I've applied your patch to commit e632b (the master e30d04 doesn't compile). Compiles Ok but same error. I need to add a metadata but HOW? Theres no annotation for metadata at https://live.gnome.org/GObjectIntrospection/Annotations Do I missing some thing?
I've added a Gda-5.0.metada to libgda/ directory with contents: After that I've called in the same directory Gda-5.0.gir and Gda-5.0.metada files exist: vapigen --pkg libxml2-2.0 --library libgda-5.0 Gda-5.0.gir Message errors are: ** (vapigen:9428): CRITICAL **: vala_symbol_set_replacement: assertion `self != NULL' failed ** (vapigen:9428): CRITICAL **: vala_symbol_set_deprecated_since: assertion `self != NULL' failed ** (vapigen:9428): CRITICAL **: vala_symbol_get_deprecated_since: assertion `self != NULL' failed ** (vapigen:9428): CRITICAL **: vala_symbol_set_deprecated_since: assertion `self != NULL' failed ** (vapigen:9428): CRITICAL **: vala_symbol_get_replacement: assertion `self != NULL' failed ** (vapigen:9428): CRITICAL **: vala_symbol_get_deprecated_since: assertion `self != NULL' failed ** (vapigen:9428): CRITICAL **: vala_symbol_set_deprecated: assertion `self != NULL' failed ** (vapigen:9428): CRITICAL **: vala_gir_parser_is_container: assertion `sym != NULL' failed ** (vapigen:9428): CRITICAL **: vala_gir_parser_add_symbol_to_container: assertion `sym != NULL' failed Gda-5.0.gir:15983.7-15983.22: error: Recursive value types are not allowed <field name="parent" writable="1"> Segmentation fault (core dumped)
The file must be called Gda-5.0.metadata not Gda-5.0.metada. You have to put it in the same directory of the gir, or alternatively use --metadatadir. I've pushed the change for marking structs as compact classes (struct=false). I have gda 4.0 gir, so the following is the contents of the metadata which might help you sorting things out: SqlErrorType skip Error skip SList skip ValueList skip SqlAnyPart struct=false SqlFunction struct=false ServerProviderMeta skip ServerProviderXa skip SqlStatementContentsInfo skip value_get_list skip value_set_list skip Skipped elements are currently unsupported / hard to support. Let me know.
Was my typo. I have a Gda-5.0.metadata file in the same directory than Gda-5.0.gir. I'm usign master b29284, with no patch applied. In Gda-5.0.metadata I've added your metadata. I get the same error. Using GDB I get: vala_struct_is_recursive_value_type (self=0x1574d20 [ValaStruct], type= 0x1618010 [ValaEnumValueType]) at valastruct.c:2245 2245 _tmp1_ = _vala_code_node_ref0 (VALA_IS_STRUCT_VALUE_TYPE (_tmp0_) ? ((ValaStructValueType*) _tmp0_) : NULL); A bt returns:
+ Trace 228073
I deleted all metadata but SqlAnyPart struct=false line, with the same result. If Vala will use GIR files, Why to create VAPI files for libraries? Requiring to create METADATA Why not just add annotations to GObject-Introspection to use a struct as a Class? If last is not possible: How I can distribute Gda-5.0.metadata file? Is this file required when I compile a vala code using GIR? Will be a {datadir}/gir-1.0/metadata directory to add metadata to?
(In reply to comment #7) > I deleted all metadata but SqlAnyPart struct=false line, with the same result. Would you upload the gir somewhere? > > If Vala will use GIR files, Why to create VAPI files for libraries? Requiring > to create METADATA > > Why not just add annotations to GObject-Introspection to use a struct as a > Class? It's not that trivial. > > If last is not possible: How I can distribute Gda-5.0.metadata file? Is this > file required when I compile a vala code using GIR? Will be a > {datadir}/gir-1.0/metadata directory to add metadata to? Just distribute the .vapi, the .metadata is vala-specific.
Created attachment 193724 [details] GIR file for GDA 5.0 development version commit f96e75 on master Gda-5.0.metadata contents: // Vala Bindings for GDA SqlAnyPart struct=false
I'm trying to get master from Vala respository but I get this errors: CC valacodenode.lo valacodenode.c: In function 'vala_code_node_set_attribute_cache': valacodenode.c:1219:89: error: macro "g_renew" requires 3 arguments, but only 2 given valacodenode.c:1219:34: error: 'g_renew' undeclared (first use in this function) valacodenode.c:1219:34: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [valacodenode.lo] Error 1 I can't fully test without make master baabed. I suspect that in my comment #6 reporting to be using master b29284 was wrong, because this problem I've reported in my #3 I have switched to e632b because master e30d04 doesn't compile.
Lately we've fixed a bug in bootstrapping vala. So you are probably compiling vala with a miscompiled vala. Solve this by cleaning up the repository and bootstrapping vala using 0.12 or a 0.13.x tarball.
Created attachment 193745 [details] gda vapi generated from Gda-5.0.gir + metadata I was able to generate the vapi with the metadata below: SqlErrorType skip Error skip SList skip ValueList skip SqlAnyPart struct=false SqlFunction struct=false ServerProviderMeta skip ServerProviderXa skip SqlStatementContentsInfo skip value_get_list skip value_set_list skip $ ../vapigen/vapigen --library gda Gda-5.0.gir Generation succeeded - 0 warning(s) Vapigen must be from vala master. I'm attaching the vapi for reference. You have to still tweak it due to wrong C headers (this can be fixed upstream) and so on. So for metadata reference please take a look at https://live.gnome.org/Vala/Manual/GIR%20metadata%20format Closing the bug. You can use the mailing list or the #vala channel on irc.gnome.org for further discussion.